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SYSTEM, METHOD AND ARTICLE OF 
MANUFACTURE FOR A GATEWAY SYSTEM 
ARCHITECTURE WITH SYSTEM 
ADMINISTRATION INFORMATION 
ACCESSIBLE FROM A BROWSER 

This application is a continuation of Ser. No. 08/721,167 
filed Sep. 26, 1996 now U.S. Pat. No. 5,591,917. 

FIELD OF THE INVENTION 

The present invention relates to the secure, electronic 
payment in exchange for goods and services purchased over 
a communication network, and more specifically, to a 
system, method and article of manufacture for securely 
transmitting payment information from a customer to a 
merchant to a payment gateway and returning a certification, 
including a credit confidence factor to allow a merchant to 
determine whether to accept or reject payment information 
utilizing a flexible, extensible architecture. 

The present invention relates to an electronic graphical 
representation of a monetary system for implementing elec- 
tronic money payments as an alternative medium of eco- 
nomic exchange to cash, checks, credit and debit cards, and 
electronic funds transfer. The Electronic-Monetary System 
is a hybrid of currency, check, card payment systems, and 
electronic funds transfer systems, possessing many of the 
benefits of these systems with few of their limitations. The 
system utilizes electronic representations of money which 
are designed to be universally accepted and exchanged as 
economic value by subscribers of the monetary system. 

Today, approximately 350 billion coin and currency trans- 
actions occur between individuals and institutions every 
year. The extensive use of coin and currency transactions has 
limited the automation of individual transactions such as 
purchases, fares, and bank account deposits and withdraw- 
als. Individual cam transactions are burdened by the need to 
have the correct amount of cash or providing change there- 
for. Furthermore, the handling and managing of paper cash 
and coins is inconvenient, costly and time consuming for 
both individuals and financial institutions. 

Although checks may be written for any specific amount 
up to the amount available in the account, checks have very 
limited transferability and must be supplied from a physical 
inventory. Paper-based checking systems do not offer suf- 
ficient relief from the limitations of cash transactions, shar- 
ing many of the inconveniences of handling currency while 
adding the inherent delays associated with processing 
checks. To this end, economic exchange has striven for 
greater convenience at a lower cost, while also seeking 
improved security. 

Automation has achieved some of these qualities for large 
transactions through computerized electronic funds transfer 
("EFT") systems. Electronic funds transfer is essentially a 
process of value exchange achieved through the banking 
system's centralized computer transactions. EFT services 
are a transfer of payments utilizing electronic "checks," 
which are used primarily by large commercial organizations. 

The Clearing House (ACH) where a user can enter a 
pre-authorized code and download information with billing 
occurring later, and a Point Of Sale (POS) system where a 
transaction is processed by connecting with a central com- 
puter for authorization for the transaction granted or denied 
immediately are examples of EFT systems that are utilized 
by retail and commercial organizations. However, the pay- 
ments made through these types of EFT systems are limited 
in that they cannot be performed without the banking 
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system. Moreover, ACH transactions usually cannot be 
performed during off business hours. 

Home Banking bill payment services are examples of an 
EFT system used by individuals to make payments from a 

5 home computer. Currently, home banking initiatives have 
found few customers. Of the banks that have offered services 
for payments, account transfers and information over the 
telephone lines using personal computers, less than one 
percent of the bank's customers are using the service. One 

10 reason that Home Banking has not been a successful product 
is because the customer cannot deposit and withdraw money 
as needed in this type of system. 

Current EFT systems, credit cards, or debit cards, which 
are used in conjunction with an on-line system to transfer 

15 money between accounts, such as between the account of a 
merchant and that of a customer, cannot satisfy the need for 
an automated transaction system providing an ergonomic 
interface. Examples of EFT systems which provide non- 
ergonomic interfaces are disclosed in U.S. Pat. Nos. 5,476, 

20 259; 5,459,304; 5,452,352; 5,448,045; 5,478,993; 5,455, 
407; 5,453,601; 5,465,291; and 5,485,510. 

To implement an automated, convenient transaction that 
can dispense some form of economic value, there has been 
a trend towards off-line payments. For example, numerous 

25 ideas have been proposed for some form of "electronic 
money" that can be used in cashless payment transactions as 
alternatives to the traditional currency and check types of 
payment systems. See U.S. Pat. No. 4,977,595, entitled 
"METHOD AND APPARATUS FOR IMPLEMENTING 

30 ELECTRONIC CASH," and U.S. Pat. No. 4,305,059, 
entitled "MODULAR FUNDS TRANSFER SYSTEM." 

The more well known techniques include magnetic stripe 
cards purchased for a given amount and from which a 

35 prepaid value can be deducted for specific purposes. Upon 
exhaustion of the economic value, the cards are thrown 
away. Other examples include memory cards or so called 
smart cards which are capable of repetitively storing infor- 
mation representing value that is likewise deducted for 

40 specific purposes. 

It is desirable for a computer operated under the control 
of a merchant to obtain information offered by a customer 
and transmitted by a computer operating under the control of 
the customer over a publicly accessible packet -switched 

45 network (e.g., the Internet) to the computer operating under 
the control of the merchant, without risking the exposure of 
the information to interception by third parties that have 
access to the network, and to assure that the information is 
from an authentic source. It is further desirable for the 

50 merchant to transmit information, including a subset of the 
information provided by the customer, over such a network 
to a payment gateway computer system that is designated, 
by a bank or other financial institution that has the respon- 
sibility of providing payment on behalf of the customer, to 

55 authorize a commercial transaction on behalf of such a 
financial institution, without the risk of exposing that infor- 
mation to interception by third parties. Such institutions 
include, for example, financial institutions offering credit or 
debit card services. 

60 One such attempt to provide such a secure transmission 
channel is a secure payment technology such as Secure 
Electronic Transaction (hereinafter "SET"), jointly devel- 
oped by the Visa and MasterCard card associations, and 
described in Visa and MasterCard's Secure Electronic 

65 Transaction (SET) Specification, Feb. 23, 1996, hereby 
incorporated by reference. Other such secure payment tech- 
nologies include Secure Transaction Technology ("STT"), 
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Secure Electronic Payments Protocol ("SEPF*), Internet 
Keyed Payments ("iKP"), Net Trust, and Cybercash Credit 
Payment Protocol. One of ordinary skill in the art readily 
comprehends that any of the secure payment technologies 
can be substituted for the SET protocol without undue 
experimentation. Such secure payment technologies require 
the customer to operate software that is compliant with the 
secure payment technology, interacting with third-party cer- 
tification authorities, thereby allowing the customer to trans- 
mit encoded information to a merchant, some of which may 
be decoded by the merchant, and some which can be 
decoded only by a payment gateway specified by the cus- 
tomer. 

Another such attempt to provide such a secure transmis- 
sion channel is a general-purpose secure communication 
protocol such as Netscape, Inc.'s Secure Sockets Layer 
(hereinafter "SSL"), as described in Freier, Karlton & 
Kocher (hereinafter "Freier"), The SSL Protocol Version 3.0, 
March 1996, and hereby incorporated by reference. SSL 
provides a means for secure transmission between two 
computers. SSL has the advantage that it does not require 
special-purpose software to be installed on the customer's 
computer because it is already incorporated into widely 
available software that many people utilize as their standard 
Internet access medium, and does not require that the 
customer interact with any third-party certification authority. 
Instead, the support for SSL may be incorporated into 
software already in use by the customer, e.g., the Netscape 
Navigator World Wide Web browsing tool. However, 
although a computer on an SSL connection may initiate a 
second SSL connection to another computer, it drawback to 
the SSL approach is each SSL connection supports only a 
two-computer connection. Therefore, SSL does not provide 
a mechanism for transmitting encoded information to a 
merchant for retransmission to a payment gateway such that 
a subset of the information is readable to the payment 
gateway but not to the merchant Although SSL allows for 
robustly secure two-paty data transmission, it does not meet 
the ultimate need of the electronic commerce market for 
robustly secure three-party data transmission. Other 
examples of general-purpose secure communication proto- 
cols include Private Communications Technology ("PCT") 
from Microsoft, Inc., Secure Hyper-Text Transport Protocol 
("SHTTP") from Terisa Systems, Shen, Kerberos, Photuris, 
Pretty Good Privacy ("PGF*) which meets the IPSEC cri- 
teria. One of ordinary skin in the art readily comprehends 
that any of the general-purpose secure communication pro- 
tocols can be substituted for the SSL transmission protocol 
without undue experimentation. 

Banks desire an Internet payment solution that emulates 
existing Point of Sale (POS) applications that are currently 
installed on their host computers, and require minimal 
changes to their host systems. This is a critical requirement 
since any downtime for a bank's host computer system 
represents an enormous expense. Currently, VeriFone sup- 
ports over fourteen hundred different payment-related appli- 
cations. The large number of applications is necessary to 
accommodate a wide variety of host message formats, 
diverse methods for communicating to a variety of hosts 
with different dial-up and direct-connect schemes, and dif- 
ferent certification around the world. In addition, there are a 
wide variety of business processes that dictate how a Point 
of Sale (POS) terminal queries a user for data and subse- 
quently displays the data. Also, various vertical market 
segments, such as hotels, car rental agencies, restaurants, 
retail sales, mail sales/telephone sales require interfaces for 
different types of data to be entered, and provide different 
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discount rates to merchants for complying with various data 
types. Moreover, a plethora of report generation mecha- 
nisms and formats are utilized by merchants that banking 
organizations work with. 

Banks are unwilling to converge on "standards" since 
convergence would facilitate switching from one acquiring 
bank to another by merchants. In general, banks desire to 
increase the cost that a merchant incurs in switching from 
one acquiring bank to another acquiring bank. This is 
accomplished by supplying a merchant with a terminal that 
only communicates utilizing the bank's proprietary protocol, 
and by providing other value-added services that a merchant 
may not be able to obtain at another bank. 

Internet-based payment solutions require additional secu- 
rity measures that are not found in conventional POS 
terminals. This additional requirement is necessitated 
because Internet communication in done over publicly- 
accessible, unsecured communication line in stark contrast 
to the private, secure, dedicated phone or leased line service 
utilized between a traditional merchant and an acquiring 

20 bank. Thus, it is critical that any solution utilizing the 
Internet for a communication backbone, employ some form 
of cryptography. 

As discussed above, the current state-of-the-art Internet 
based payment processing is a protocol referred to as SET. 

25 Since the SET messages are uniform across all 
implementations, banks cannot differentiate themselves in 
any reasonable way. Also, since SET is not a proper superset 
of all protocols utilized today, there are bank protocols 
which cannot be mapped or translated into SET because they 

30 require data elements for which SET has no placeholder. 
Further, SET only handles the message types directly related 
to authorizing and capturing credit card transactions and 
adjustments to these authorizations or captures. In a typical 
POS terminal in the physical world, these messages com- 
prise almost the entire volume of the total number of 

35 messages between the merchant and the authorizing bank, 
but only half of the total number of different message types. 
These message types, which are used infrequently, but 
which are critical to the operation of the POS terminal must 
be supported for proper transaction processing. 

40 

SUMMARY OF THE INVENTION 
According to a broad aspect of a preferred embodiment of 
the invention, a server communicates bidirectionally with a 
gateway over a first communication fink, over which all 

45 service requests are initiated by the server. Secure transmis- 
sion of data is provided from a customer computer system to 
a merchant computer system, and for the further secure 
transmission of payment information regarding a payment 
instrument from the merchant computer system to a payment 

50 gateway computer system. The payment gateway system 
receives encrypted payment requests from merchants, as 
HTTP POST messages via the Internet. The gateway then 
unwraps and decrypts the requests, authenticates digital 
signatures of the requests based on certificates, supports 

55 transaction types and card types as required by a financial 
institution, and accepts concurrent VPOS transactions from 
each of the merchant servers. Then, the gateway converts 
transaction data to host-specific formats and forwards the 
mapped requests to the host processor using the existing 

60 financial network. The gateway system architecture includes 
support for standard Internet access routines which facilitate 
access to system administration information from a com- 
mercial web browser. 

DESCRIPTION OF THE DRAWINGS 

to 

The foregoing and other objects, aspects and advantages 
are better understood from the following detailed description 
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of a preferred embodiment of the invention with reference to FIGS. 20A-20H are block diagrams and flowcharts sct- 

the drawings, in which: ting forth the detailed logic of thread processing in accor- 

FIG. 1A is a block diagram of a representative hardware dance with a preferred embodiment; 

environment in accordance with a preferred embodiment; FIG. 21 is a detailed diagram of a multithreaded gateway 

FIG. IB depicts an overview in accordance with a pre- 5 engine in accordance with a preferred embodiment; 

ferred embodiment; FIG. 22 is a flow diagram in accordance with a preferred 

FIG 1C is a block diagram of the system in accordance embodiment; 

with a preferred embodiment; FIG. 23 illustrates a Gateways role m a network m 

FIG 2 depicts a more detailed view of a customer 10 accordance with a preferred embodiment; 

computer system in communication with merchant system FIG. 24 is a block diagram of the Gateway in accordance 

under the Secure Sockets Layer protocol in accordance with with a preferred embodiment; 

a preferred embodiment; FIG. 25 is a block diagram of the VPOS Terminal 

FIG. 3 depicts an overview of the method of securely Architecture in accordance with a preferred embodiment; 

supplying payment information to a payment gateway in is FIG. 26 is an architecture block diagram in accordance 

order to obtain payment authorization in accordance with a with a preferred embodiment; 

preferred embodiment; FIG. 27 is a block diagram of the payment manager 

FIG. 4 depicts the detailed steps of generating and trans- architecture in accordance with a preferred embodiment; 

mining a payment authorization request in accordance with FIG. 28 is a Consumer Payment Message Sequence 

a preferred embodiment; 20 Diagram in accordance with a preferred embodiment of the 

FIGS. 5 A through 5F depict views of the payment autho- invention; 

rization request and its component parts in accordance with FIG. 29 is an illustration of a certificate issuance form 

a preferred embodiment; accordance with a preferred embodiment; 

FIGS. 6A and 6B depict the detailed steps of processing n$ FIG. 30 illustrates a certificate issuance response in accor- 

a payment authorization request and generating and trans- " dance with a preferred embodiment; 

mitting a payment authorization request response in accor- FIG. 31 illustrate a collection of payment instrument 

dance with a preferred embodiment; holders in accordance with a preferred embodiment; 

FIGS. 7A through 7J depict views of the payment autho- FIG. 32 illustrates the default payment instrument bitmap 

rization response and its component parts in accordance with 30 in accordance with a preferred embodiment; 

a preferred embodiment; FIG. 33 illustrates a selected payment instrument with a 

FIG. 8 depicts the detailed steps of processing a payment fill in the blanks for the cardholder in accordance with a 

authorization response in accordance with a preferred preferred embodiment; 

embodiment; FIG. 34 illustrates a coffee purchase utilizing the newly 

FIG. 9 depicts an overview of the method of securely ^ defined VISA card in accordance with a preferred embodi- 

supplying payment capture information to a payment gate- ment of the invention; 

way in accordance with a preferred embodiment; FIG. 35 is a flowchart of conditional authorization of 

FIG 10 depicts the detailed steps of generating and payment in accordance with a preferred embodiment; 

transmitting a payment capture request in accordance with a ^ FIGS. 36^8 are screen displays in accordance with a 

preferred embodiment; preferred embodiment; 

FiGS 11A through 11F depict views of the payment FIG. 49 shows how the VPOS authenticates an incoming 

capture request and its component parts in accordance with response to a request in accordance with a preferred embodi- 

a preferred embodiment; ment; 

FIGS 12Aandl2B depict the detailed steps of processing 45 FIG- 50 is a flowchart for the merchant interaction with 

a payment capture request and generating and transmitting a the Test Gateway in accordance with a preferred embodi- 

payment capture request response in accordance with a ment; 

preferred embodiment; FIGS. 51-61 are flowcharts depicting the detailed logic of 

FIGS. 13A through 13F depict views of the payment the gateway in accordance with a preferred embodiment; 

capture response and its component parts in accordance with 50 FIG. 62 is the main administration display for the Gate- 

a preferred embodiment; way in accordance with a preferred embodiment; 

RG. 14 depicts the detailed steps of processing a payment FIG. 63 is a configuration panel in accordance with a 

capture response in accordance with a preferred embodi- preferred embodiment; 

ment; FIG. 64 is a host communication display for facilitating 

FIGS 15A & 15B depicts transaction processing of 55 communication between the gateways and the acquirer 

merchant and consumer transactions in accordance with a payment host in accordance with a preferred embodiment; 

preferred embodiment; FIG. 65 is a Services display in accordance with a 

FIG. 16 illustrates a transaction class hierarchy block preferred embodiment; 

diagram in accordance with a preferred embodiment; 6Q FIG. 66 is a graphical representation of the gateway 

FIG. 17 shows a typical message flow between the transaction database in accordance with a preferred embodi - 

merchant, VPOS terminal and the Gateway in accordance ment; 

with a preferred embodiment; FIG. 67 illustrates the gateway hardware architecture in 

FiGS. 18A-E are block diagrams of the extended SET accordance with a preferred embodiment; 

architecture in accordance with a preferred embodiment; 65 FIG. 68 is a block diagram setting forth the gateway 

FIG. 19 is a flowchart of VPOS merchant pay customi- software architecture in accordance with a preferred 

zation in accordance with a preferred embodiment; embodiment; and 
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FIG. 69 is a block diagram setting forth the gateway of the clam of objects, which is often just called a class. A 

components and interfaces in accordance with a preferred class of objects can be viewed as a blueprint, from which 

embodiment. many objects can be formed. 

DETAILED DESCRIPTION OOP allows the programmer to create an object that is a 

, . .5 part of another object. For example, the object representing 

A preferred embodiment of a system in accordance with & q & fe ^ tQ hflve a compositiorj _ re lationship 

the present invention is preferably practiced ^in the context of ^ ^ a pist0D . In realitv , a piston 

a personal computer such as the IBM PS/2, Apple Macintosh g rises a ist0Q> valves aod many other ^po. 

computer or UNIX based workstation. A representative ^ ^ ^ & piston fa an clcmem of a pist0Q engiae 

hardware environment is depicted in FIG^ 1A, which illus- 1Q ^ ^ { .„ ^ ^^t^y repre sented in OOP by two 

trates a typical hardware configuration of a workstation in objects 

accordance with a preferred embodiment having a central p ^ ^ 

proce^ng unit 10, such as a microprocessor, and a number J Qne £ 

of otto units unconnected via a system bus 12 . Th e engine and the other representing a piston 

workstation shown in FIG. 1A includes a Random Access , ^"^"K F , . . . ■ *',„_;_ , h _„ , hp 

Memory (RAM) 14, Read Only Memory (ROM) 16, an I/O 15 en 8™ therein the pston is made of cerannc then ihe 

adapter 18 for connecting peripheral devices such as disk relationship between the two objects is not that of compo- 

F & r r . sition. A ceramic piston engine does not make up a piston 

stora g C «m tt 20tolhetol2,.user^rf«^ato . Ralher it ismerel y one kind of piston engine that has 

connecting a keyboard 24, a mouse 26, a speaker 28, a | * ^ Qn ig ma(Je 

microphone 32 and/or other user interface devices such as M P ^ J lhe ceramic 

a touch screen (not shown) to the bus 12, commumcation ' . ' r , , 7 . o11 „ f 

, v ■ .u i , L . „ piston engine is called a derived object, and it inherits all of 

adapter 34 for connecting the workstation to a communica- ^ 6 , . t . J ! ♦ . „ mrtd 

. ^ : ' , 5 . . iv j ,, tl the aspects of the object representing the piston engine and 

p , : • ,, . j . .u .„ the ceramic piston engine "depends from' the object repre- 

The workstation tvpicallv has resident thereon an operating ^ . "7 v . 6 . "I „,.,;„„„u,„ .L^ 

u W ' r. n; j ... kit ncJ™«(o? senting the piston engine. The relationship between these 

system such as the Microsoft Windows NT or Windows/<o » „L„„„ 

Operating System (OS), the IBM OS/2 operating system, the objects is caUed inhenunce. 

MAC OS, or UNIX operating system. Those skilled in the When the object or class representing the ceramic piston 

art will appreciate that the present invention may also be engine inherits all of the aspects of the objects representing 

implemented on platforms and operating systems other man 30 the piston engine, it inherits the thermal characteristics of a 

those mentioned standard piston defined in the piston engine class. However, 

Apreferred embodiment is written using JAVA, C, and the the ceramic piston engine object overrides these ceramic 

C + 7Lguage and utilizes object oriented programming speafic thermal characteristics, which are typically dtferen, 

, j f 6 ^ - ♦ A /n n p\ h * from those associated with a metal piston. It skips over the 

methodology. Object oriented programm ^ ^ * tQ ceramic ^ 

become increasingly used to develop complex applications. 35 i - j r • . ■ . e j-fr„p„t 

As OOP moves toward the mainstream of software design Different kinds of piston engines have d_ fc 

and development, various software solutions require adap- characteristics but may have the same underlying runcUoDS 

Son to mL.se of the benefits of OOP. A need exists for associated « e.g., how many patons in he engine^ 

these principles of OOP to be applied to a messaging sequences, lubrication, e ' c >- Jo a^ each of these 

interface of an electronic messaging system such that a set w ^lions » anv P 1 ? 00 engine object, a programmer would 

of OoTctses and object for the messaging interface can 40 call the same functrons with the ^^^^S 

"... 3 of piston engine may have different/overriding unplemen- 

.... , f. ,. tations of functions behind the same name. This ability to 

OOP is a process of developing computer software using lementations of a faction behind the same 

objects, including the steps of analyzing the problem polymorphism and it greatly simplifies com- 

designing the system, and constructing the program. An 45 mumcation objects. 

object is a software package that contains both data and a c ■•• „,„ : „„i,:„ 

collection of related structures and procedures. Since it With the concepts of composition-relationship 

contains both data and a collection of structures and encapsulation, inhentanc. >and polymorphism « 1 object can 

procedures, it can be visualized as a self-sufficient compo- represent just about anything m the real world. In fact, our 

nent that does not require other additional structures, pro- 50 log** W? 1 ™ °f the reality «« ** ^ 1™« ° n de.er- 

cedures or data to perform its specific task. OOP, therefore, mining the kinds of things that can becom< ^ objects m 

views a computer program as a^ollection of largely autono- object-oriented software. Some typical categories are as 

mous components, called objects, each of which is respon- follows. 

sible for a specific task. This concept of packaging data, Objects can represent physical objects, such as automo- 

structures, and procedures together in one component or 55 biles in a trafBc-flow simulaUon, electrical components 

module is called encapsulation. * a circuit-design program, countries m an economics 

In general, OOP components are reusable software mod- model, or aircraft in an air-tra£5c-control system, 

ules which present an interface that conforms to an object Objects can represent elements of the computer-user 

model and which are accessed at run-time through a com- environment such as windows, menus or graphics 

ponent integration architecture. A component integration 60 objects. 

architecture is a set of architecture mechanisms which allow An object can represent an inventory, such as a personnel 

software modules in different process spaces to utilize each file or a table of the latitudes and longitudes of cities, 

others capabilities or functions. This is generally done by An object can represent user-defined data type such as 

assuming a common component object model on which to time, angles, and complex numbers, or points on the 

build the architecture. 65 plane. 

It is worthwhile to differentiate between an object and a With this enormous capability of an object to represent 

class of objects at this point. An object is a single instance just about any logically separable matters, OOP allows the 



06/10/2004, EAST Version: 1.4.1 



US 6,304,! 

9 

software developer to design and implement a computer 
program that is a model of some aspects of reality, whether 
that reality is a physical entity, a process, a system, or a 
composition of matter. Since the object can represent 
anything, the software developer can create an object which 5 
can be used as a component in a larger software project in 
the future. 

If 90% of a new OOP software program consists of 
proven, existing components made from preexisting reus- 
able objects, then only the remaining 10% of the new 1Q 
software project has to be written and tested from scratch. 
Since 90% already came from an inventory of extensively 
tested reusable objects, the potential domain from which an 
error could originate is 10% of the program. As a result, 
OOP enables software developers to build objects out of 
other, previously built, objects. 15 

This process closely resembles complex machinery being 
built out of assemblies and sub-assemblies. OOP 
technology, therefore, makes software engineering more like 
hardware engineering in that software is built from existing 
components, which are available to the developer as objects. 20 
All this adds up to an improved quality of the software as 
well as an increased speed of its development. 

Programming s are beginning to fully support the OOP 
principles, such as encapsulation, inheritance, 
polymorphism, and composition-relationship. With the 25 
advent of the C++ language, many commercial software 
developers have embraced OOP. C++ is an OOP language 
that offers a fast, machine -executable code. Furthermore, 
C++ is suitable for both commercial-application and system- 
programing projects. For now, C++ appears to be the most 30 
popular choice among many OOP programmers, but there is 
a host of other OOP languages, such as Smalltalk, common 
lisp object system (CLOS), and Eiffel. Additionally, OOP 
capabilities are being added to more traditional popular 
computer programming languages such as Pascal. 35 

The benefits of object classes can be summarized, as 
follows: 

Objects and their corresponding classes break down com- 
plex programming problems into many smaller, sim- 
pler problems. 

Encapsulation enforces data abstraction through the orga- 
nization of data into small, independent objects that can 
communicate with each other. Encapsulation protects 
the data in an object from accidental damage, but 
allows other objects to interact with that data by calling 
the object's member functions and structures. 

Subclassing and inheritance make it possible to extend 
and modify objects through deriving new kinds of 
objects from the standard classes available in the sys- 5Q 
tem. Thus, new capabilities are created without having 
to start from scratch. 

Polymorphism and multiple inheritance make it possible 
for different programmers to mix and match character- 
istics of many different classes and create specialized 55 
objects that can still work with related objects in 
predictable ways. 

Class hierarchies and containment hierarchies provide a 
flexible mechanism for modeling real -world objects 
and the relationships among them. 60 

Libraries of reusable classes are useful in many situations, 
but they also have some limitations. For example: 

Complexity. In a complex system, the class hierarchies for 
related classes can become extremely confusing with 
many dozens or even hundreds of classes. 65 

Flow of control. A program written with the aid of class 
libraries is still responsible for the flow of control (i.e., 
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it must control the interactions among all the objects 
created from a particular library). The programmer has 
to decide which functions to call at what time for which 
kinds of objects. 
Duplication of effort. Although class libraries allow pro- 
grammers to use and reuse many small pieces of code, 
each programmer puts those pieces together in a dif- 
ferent way. Two different programmers can use the 
same set of class libraries to write two programs that do 
exactly the same thing but whose internal structure 
(i.e., design) may be quite different, depending on 
hundreds of small decisions each programmer makes 
along the way. Inevitably, similar pieces of code end up 
doing similar things in slighdy different ways and do 
not work as well together as they should. 
Class libraries are very flexible. As programs grow more 
complex, more programmers are forced to reinvent basic 
solutions to basic problems over and over again. A relatively 
new extension of the class library concept is to have a 
framework of class libraries. This framework is more com- 
plex and consists of significant collections of collaborating 
classes that capture both the small scale patterns and major 
mechanisms that implement the common requirements and 
design in a specific application domain. They were first 
developed to free application programmers from the chores 
involved in displaying menus, windows, dialog boxes, and 
other standard user interface elements for personal comput- 
ers. 

Frameworks also represent a change in the way program- 
mers think about the interaction between the code they write 
and code written by others. In the early days of procedural 
programming, the programmer called libraries provided by 
the operating system to perform certain tasks, but basically 
the program executed down the page from start to finish, and 
the programmer was solely responsible for the flow of 
control. This was appropriate for printing out paychecks, 
calculating a mathematical table, or solving other problems 
with a program that executed in just one way. 

The development of graphical user interfaces began to 
turn this procedural programming arrangement inside out. 
These interfaces allow the user, rather than program logic, to 
drive the program and decide when certain actions should be 
performed. Today, most personal computer software accom- 
plishes this by means of an event loop which monitors the 
mouse, keyboard, and other sources of eternal events and 
calls the appropriate parts of the programmer's code accord- 
ing to actions that the user performs. The programmer no 
longer determines the order in which events occur. Instead, 
a program is divided into separate pieces that are called at 
unpredictable times and in an unpredictable order. By relin- 
quishing control in this way to users, the developer creates 
a program that is much easier to use. Nevertheless, indi- 
vidual pieces of the program written by the developer still 
call libraries provided by the operating system to accomplish 
certain tasks, and the programmer must still determine the 
flow of control within each piece after it's called by the 
event loop. Application code still "sits on top of the system. 

Even event loop programs require programmers to write 
a lot of code that should not need to be written separately for 
every application. The concept of an application framework 
carries the event loop concept further. Instead of dealing 
with all the nuts and bolts of constructing basic menus, 
windows, and dialog boxes and then making these things all 
work together, programmers using application frameworks 
start with working application code and basic user interface 
elements in place. Subsequently, they build from there by 
replacing some of the generic capabilities of the framework 
with the specific capabilities of the intended application. 
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Application frameworks reduce the total amouot of code other protocols could be readily substituted for HTML 

that a programmer has to write from scratch. However, without undue experimentation. Information on these prod- 

because the framework is really a generic application that ucts is available in T. Berners-Lee, D. Connoly, "RFC 1866: 

displays windows, supports copy and paste, and so on, the Hypertext Markup Language— 2.0" (November 1995); and 

programmer can also relinquish control to a greater degree 5 r. Fielding, H, Frystyk, T. Berners-Lee, J. Gettys and J. C. 

than event loop programs permit. The framework code takes Mogul, "Hypertext Transfer Protocol — HTTP/1.1: HTTP 

care of almost all event handling and flow of control, and the Working Group Internet Draft" (May 2, 1996). HTML is a 

programmer's code is called only when the framework simple data format used to create hypertext documents that 

needs it (e.g., to create or manipulate a proprietary data are portable from one platform to another. HTML docu- 

structure). 10 meats are SGML documents with generic semantics that are 

A programmer writing a framework program not only appropriate for representing information from a wide range 

relinquishes control to the user (as is also true for event loop 0 f domains. HTML has been in use by the World-Wide Web 

programs), but also relinquishes the detailed flow of control global information initiative since 1990. HTML is an appli- 

within the program to the framework. This approach allows cat j oa of ISO Standard 8879:1986 Information Processing 

the creation of more complex systems that work together in 15 Texl an£ j office Systems; Standard Generalized Markup 

interesting ways, as opposed to isolated programs, having Language (SGML). 

custom code, being created over and over again for similar j 0 date, Web development tools have been limited in their 

problems. ability to create dynamic Web applications which span from 

Thus, as is explained above, a framework basically is a c y ent l0 server and interoperate with existing computing 

collection of cooperating classes that make up a reusable 20 res0 urces. Until recently, HTML has been the dominant 

design solution for a given problem domain. It typically technology used in development of Web-based solutions, 

includes objects that provide default behavior (e.g., for However, HTML has proven to be inadequate in the fol- 

menus and windows), and programmers use it by inheriting lowing areas: 

some of that default behavior and overriding other behavior p oor pcr f 0 rmance; 

so that the framework calls application code at the appro- M Rcslricted ^ interface capabilities; 

priate times. TTiere are three main differences between ^ ^ ^ ^ ^ 

frameworks and class libraries: interoperability with existing applications and 

Behavior versus protocol. Class libraries are essentially UL uuciupw / & rv 

collections of behaviors that you can call when you data > ana 

want those individual behaviors in your program. A 30 Inability to scale. 

framework, on the other hand, provides not only behav- Sun Microsystem^ Java language solves many of the 

ior but also the protocol or set of rules that govern the client-side problems by: 

ways in which behaviors can be combined, including Improving performance on the client side; 

rules for what a programmer is supposed to provide Enabling the creation of dynamic, real-time Web appli- 

versus what the framework provides. 35 cations; and 

Call versus override. With a class library, the code the Providing the ability to create a wide variety of user 

programmer instantiates objects and calls their member interface components. 

functions It's possible to instantiate and call objects in With Java, developers can create robust User Interface 
the same way with a framework (i.e., to treat the (UI) components. Custom "widgets" (e.g. real-tmae stock 
framework as a class library), but to take full advantage 40 tickers, animated icons, etc.) can be created, and client-side 
of a framework's reusable design, a programmer typi- performance is improved. Unlike HTML, Java supports the 
cally writes code that overrides and is called by the notion of client-side validation, offloading appropriate pro- 
framework. The framework manages the flow of con- cessing onto the client for improved performance. Dynamic, 
trol among its objects. Writing a program involves real-time Web pages can be created. Using the above- 
dividing responsibilities among the various pieces of 45 mentioned custom UI components, dynamic Web pages can 
software that are called by the framework rather than also be created. 

specifying how the different pieces should work Sun's Java language has emerged as an industry- 
together recognized language for "programing the Internet." Sun 
Implementation versus design. With class libraries, pro- defines Java as: "a simple, object-oriented, distributed, 
grammers reuse only implementations, whereas with 50 interpreted, robust, secure, architecture-neutral portable, 
frameworks, they reuse design. A framework embodies high-performance, multithreaded, dynamic, buzzword- 
the way a family of related programs or pieces of compliant, general-purpose language. Java supports pro- 
software work. It represents a generic design solution gramming for the Internet in the form of plattorm- 
that can be adapted to a variety of specific problems in independent Java applets." Java applets are sma 1, 
a given domain. For example, a single framework can 55 specialized applications that come with Sun s Java Apph- 
embody the way a user interface works, even though cation Programming Interface (API) allowing developers o 
two different user interfaces created with the same add "interactive content" to Web documents (e g. simple 
framework might solve quite different interface prob- animations, page adornments, basic games, etc.). Applets 
lems execute within a Java-compatible browser (e.g. Netscape 
Thus through the development of frameworks for solu- 60 Navigator) by copying code from the server to client. From 
lions to' various problems and programming tasks, signifi- a language standpoint, Java's core feature set is based on 
cant reductions in the design and development effort for C++. Sun's Java literature states ^that Java is .basically C++ 
software can be achieved. A preferred embodiment of the with extensions from Objective C for more dynamic method 
invention utilizes HyperText Markup Language (HTML) to resolution". 

implement documents on the Internet together with a 65 Another technology that provides simitar function to 

general-purpose secure communication protocol for a trans- JAVA is provided by Microsoft and ActiveX Technologies 

port medium between the client and the merchant. HTTP or to give developers and Web designers wherewithal to build 
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dynamic content for the Internet and personal computers. 
ActiveX includes tools for developing animation, 3-D vir- 
tual reality, video and other multimedia content. The tools 
use Internet standards, work on multiple platforms, and are 
being supported by over 100 companies. The group's build- 
ing blocks are called ActiveX Controls, small, fast compo- 
nents that enable developers to embed parts of software in 
hypertext markup language (HTML) pages. ActiveX Con- 
trols work with a variety of programming languages includ- 
ing Microsoft Visual C+4, Borland Delphi, Microsoft Visual 
Basic programming system and, in the future, Microsoft's 
development tool for Java, code named "Jakarta." ActiveX 
Technologies also includes ActiveX Server Framework, 
allowing developers to create server applications. One of 
ordinary skill in the art readily recognizes that ActiveX 
could be substituted for JAVA without undue experimenta- 
tion to practice the invention. 

FIG. IB depicts an overview of the present invention. 
Customer computer system 120 is in communication with 
merchant computer system 130. The customer-merchant 
session 150 operates under a general-purpose secure com- 
munication protocol such as the SSL protocol. Merchant 
computer system 130 is additionally in communication with 
payment gateway computer system 140. A payment gateway 
is a system that provides electronic commerce services in 
support of a bank or other financial institution, and that 
interfaces to the financial institution to support the authori- 
zation and capture of transactions. The customer-institution 
session 170 operates under a variant of a secure payment 
technology such as the SET protocol, as described herein, 
referred to as Merchant-Originated Secure Electronic Trans- 
actions ("MOSET"), as is more fully described herein. 

FIG. 2 depicts a more detailed view of customer computer 
system 120 in communication with merchant stem 130 using 
customer-merchant session 150 operating under the SSL 
protocol as documented in Freier and incorporated by ref- 
erence. 

Customer computer system 120 initiates communication 
with merchant computer system 130 using any well-known 
access protocol, e.g., Transmission Control Protocol/Internet 
Protocol ("TCP/IP"). A description of TCP/IP is provided in 
Information Sciences Institute, "Transmission Control Pro- 
tocol DARPA Internet Program Protocol Specification (RFC 
793)" (September, 1981), and Information Sciences 
Institute, "Internet Protocol DARPA Internet Program Pro- 
tocol Specification (RFC 791)" (September, 1981). In this 
implementation, customer computer system 120 acts as a 
client and merchant computer system 130 acts as a server. 

Customer computer system 120 initiates communication 
by sending "client hello" message 210 to the merchant 
computer system 130. When a client first connects to a 
server it is required to send the client hello message 210 as 
its first message. The client can also send a client hello 
message 210 in response to a hello request on its own 
initiative in order to renegotiate the security parameters in an 
existing connection. The client hello message includes a 
random structure, which is used later in the protocol. 
Specifically, the random structure includes the current time 
and date in standard UNIX 32-bit format according to the 
sender's internal clock and twenty-eight bytes of data gen- 
erated by a secure random number generator. The client 
hello message 210 further includes a variable length session 
identifier. If not empty, the session identifier value identifies 
a session between the same client and server whose security 
parameters the client wishes to reuse. The session identifier 
may be from an earlier connection, the current connection, 
or another currently active connection. It is useful to specify 
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the current connection if the client only wishes to update the 
random structures and derived values of a connection. It is 
useful to specify another currently active connection if the 
client wishes to establish several simultaneous independent 

5 secure connections to the same server without repeating the 
full handshake protocol. Client hello message 210 further 
includes an indicator of the cryptographic algorithms sup- 
ported by the client in order of the client's preference, 
ordered according to client preference. 

10 In response to client hello message 210, if merchant 
computer system 130 wishes to correspond with customer 
computer system 120, it responds with server hello message 
215. If merchant computer system 130 does not wish to 

15 communicate with customer computer system 120, it 
responds with a message, not shown, indicating refusal to 
communicate. 

Server hello message 215 includes a random structure, 
which is used later in the protocol. The random structure in 
20 server hello message 215 is in the same format as, but has 
contents independent of, the random structure in client hello 
message 210. Specifically, the random structure includes the 
current time and date in standard UNIX 32-bit format 
according to the sender's internal clock and twenty-eight 
25 bytes of data generated by a secure random number genera- 
tor. Server hello message 215 further includes a variable 
length session identifier. The session identifier value iden- 
tifies a new or existing session between the same client and 
server. Server hello message 215 further includes an indi- 
30 cator of the cryptographic algorithms selected from among 
the algorithms specified by client hello message 210, which 
is utilized in further encrypted communications. 

Optionally, Merchant computer system 130 transmits a 
server certificate 220. If transmitted, server certificate 130 
35 enables customer computer system 120 to authenticate the 
identity of merchant computer system 130. 

If merchant computer system 130 does not transmit a 
server certificate 220, or if server certificate 220 is suitable 
only for authentication, it may optionally transmit a server 
40 key exchange message 225. Server key exchange message 
225 identifies a key that may be used by customer computer 
system 120 to decrypt further messages sent by merchant 
computer system 130. 

After transmitting server hello message 215, and option- 
45 ally transmitting server certificate 220 or server key 
exchange message 225, merchant computer system 130 
transmits a server hello done message 230 and waits for a 
further response from customer computer system 120. 
Customer computer system 120 optionally transmits cli- 
50 ent certificate 240 to merchant computer system 130. If 
transmitted, client certificate 240 enables merchant com- 
puter system 130 to authenticate the identity of customer 
computer system 120. Alternatively, customer computer 
system 120 may transmit a no-client-certificate alert 245, to 
55 indicate that the customer has not registered with any 
certification authority. 

If customer computer system 130 does not transmit a 
client certificate 240, or if client certificate 240 is suitable 
only for authentication, customer computer system 130 may 
60 optionally transmit a client key exchange message 250. 
Client key exchange message 250 identifies a key that may 
be used by merchant computer system 130 to decrypt further 
messages sent by customer computer system 120. 

After optionally transmitting client certificate 240, 
no-client-certificate alert 245, and/or client key exchange 
message 250, customer computer system 120 transmits a 
finished message 260. 
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At this point, customer computer system 120 and mer- FIG. 3 depicts an overview of the method of securely 

chant computer system 130 have: supplying payment information to a payment gateway in 

1) negotiated an encryption scheme that may be com- order to obtain payment authorization. In function block 
monly employed in further communications, and ™, ™rchant computer system 130 generates a payment 

. , ,.5 authorization request 315 and transmits it to payment gate- 

2) have communicated to each other a set of encryption ^ m , n Wock 330 , 
keys that may be used to decrypt further communica- ' > m ^ ^ authorization 
lions between the two computer systems. generates a payment authorization response 325 and 

Customer computer system 120 and merchant computer l0 mer( £ anl computer system 130. In function 

system 130 may thereafter engage in secure communications w ^ cQm 13Q processes pay . 

270 with less risk of interception by third parties. ^ authorization r e 325 ^ dete rmines whether 

Among the messages communicated by customer com- for ^ of m ^ ^ oblained by 

puter system 120 to merchant computer system 130 may be ^ authofized 
messages that specify goods or services to be ordered ana 

payment information, such as a credit card number and Payment Authorization Request Generation 
related information, collectively referred to as "payment 

information " that may be used to pay for the goods and/or FIG. 4 depicts the detailed steps of generating and trans- 
services ordered. In order to obtain payment, the merchant mitting a payment authorization request. FIGS. 5A through 
must supply this information to the bank or other payment 5F depict views of the payment authorization request and its 
gateway responsible for the proffered payment method. This component parts. In function block 410, merchant computer 
enables the merchant to perform payment authorization and 20 system 130 creates a basic authorization request 510. The 
payment capture. Payment authorization is the process by basic authorization request is a data area that includes all the 
which permission is granted by a payment gateway operat- information for determining whether a request should be 
ing on behalf of a financial institution to authorize payment granted or denied. Specifically, it includes such information 
on behalf of the financial institution. This is a process that ^ as the party who is being charged, the amount to be charged, 
assesses transaction risk, confirms that a given transaction 25 the account number of the account to be charged, and any 
does not raise the account holder's debt above the account's additional data, such as passwords, needed to validate the 
credit limit, and reserves the specified amount of credit. charge. This information is either calculated based upon 
Payment capture is the process that triggers the movement of prior customer merchandise selection, or provided by the 
funds from the financial institution to the merchant's customer over the secure link 270 established in the 
account after settlement of the account. 30 customer-merchant general-purpose secure communication 

protocol session. FIG. 5 A depicts a basic authorization 
Payment Authorization request 510. 
Merchants utilize point-of-sale products for credit and In function block 420 merchant computer systerr ,130 
debit transactions on a daily basis. An embodiment in 35 comblDes basic authorization request 510 a copy of s 
accordance with the subject invention allows an acquirer encryption public key certmca te 515 * «W of >J 
processor to accept transactions from Interne, storefronts signature public key certificate 520 Merchant compuur 
without altering a current host environment. The system system 130 calculates a digital signature ,52! i for he corn- 
easily converts payment protocol messages and simulta- bined contents of the combined block 530 comprising basic 
neously manages transactions from a number of Internet „ authorization request 510, the encryption pubhc key certifi- 
merchL servers. As the number of transactor* grows, the cate 515 and the signature pubhc key certificate 520 and 
payment gateway can be scaled to handle the increased appends it to the combination of the combined basic autho- 
business, led it can be configured .0 work with specific nzation request 510, the encrypt™ public key create 
business processes used by the acquirer/processor. Thus, the 515 and the stgnature pubhc key certificate 520. The mer- 
paymentgateway supports Internet processing utilizing pay- 45 « hanl c ° m P u,er »£ a « n calculates digital S1 gna ure 525 by 
ment processing Operations. ^ calculating a "message digest' based upon the contents 

„ .. „ , of the combined basic authorization request 510, the encryp- 

The payment gateway provides support for configuring aQ(J ^ Mic k 

and instalhng the Internet paymentcapability utibzing ex*t- ? * fixed-length result 

^^^^^■T^^y^^S? ffl that is generated when a variable length message is fed into 

provides an intuitive Graphical User Interface (GUJ w b 50 * e he| verjfy 

support bu.lt m to accommodate foture payment instruments J £ ^ ^ 

such as debit cards, electrons checks, electronic cash and ^ ^ e ^ fc 

micropayments. The payment gateway impkments secure f * ^ a g m 

l r r aC ^°^ U r Sin8 c R P«bbc-key cryptography aa d the * ^ f a gj 

MasterCard/Visa Secure Electromc Transaction (SET) pro- 55 m 

tocol. The gateway also provides full functionality for re * mn J . . . . . , _- n , , , 
merchant payment processing including authorization, FIG. 5B depicts the combined block 530 formed by 
capture, settlement and reconciliation while providing moni- fraction block 420 and containing basic authonzaUon 
tor activity with reporting and tracking of transactions sent request 510, the encryption pubhc key certificate 515 the 
over the Internet. Finally, the payment gateway also imple- 60 signature public key certificate 520, and digital Pasture 525. 
ments Internet payment procedures that match current pro- In function block 430, merchant computer system 130 
cessor business models to ensure consistency for merchants. generates a random encryption key RK-0 540, denoted as 
Handling Internet transactions is destined to become a RK-0. Random encryption key RK-0 540 is a symmetric 
necessary function for every payment processing system. encryption key. A symmetric encryption key is a key char- 
Today, merchants often transmit data received over the 65 acterized by the property that a message encrypted with a 
Internet inefficiently. Some fax the information or waste symmetric key can be decrypted with that same key. This is 
time keying data into a non-Internet system. contrasted with an asymmetric key pair, such as a public- 
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key/private-key key pair, where a message encrypted with digest calculated by merchant computer system 130 in 

one key of the key pair may only be decrypted with the other function block 420. If the two message digests are equal, the 

key of the same key pair. FIG . 5C depicts random encryption digital signature 525 is validated. If validation fails, payment 

key RK-0 540. gateway computer system 140 rejects the authorization 

In function block 440, merchant computer system 130 5 request 
encrypts combined block 530 using random encryption key In function block 630, payment gateway computer system 
RK-0 540 to form encrypted combined block 550. FIG. 5D 140 determines the financial institution for which authori- 
depicts encrypted combined block 550. The encryption state zation is required by inspection of basic authorization 
of encrypted combined block 550 is graphically shown by request 510. Payment gateway computer system 140 con- 
random key lock 555, which indicates that encrypted com- io tacts the appropriate financial institution using a secure 
bined block 550 is encrypted using random key RK-0 540. means, e.g, a direct-dial modem-to-modem connection, or a 

In function block 450, merchant computer system 130 proprietary internal network that is not accessible to third 

encrypts random encryption key RK-0 540 using the public Pities, and using prior art means, obtains a response indi- 

key of payment gateway system 140 to form encrypted eating whether the request payment is authorized, 

random key 560. FIG. 5E depicts encrypted random key 15 Payment Authorization Response Generation 

560. The encryption state of encrypted random key 560 is , . , , 

graphically shown by payment gateway public key lock 565, Function blocks 635 through 685 depict the steps of 

which indicates that encrypted random key 560 is encrypted generating and transmitting a payment authorization request 

using the payment gateway public key. response FIGS. 7A through 7J depict views of the payment 

In function block 460, merchant computer system 130 20 authorization response and its component parts, 

concatenates encrypted combined block 550 and encrypted In function block 635 payment gateway computer system 

randomkey560toformmercbantauthoriz a tionrequest315. 140 creates a basic authorization response 710. The basic 

FIG. 5F depicts merchant authorization request 315 com- authorization request is a data area that includes all the 

prising encrypted combined block 550 and encrypted ran- „ information to determine whether a request was granted or 

dom key 560 In function block 470, merchant computer 25 denied. FIG. 7A depicts basic authorization response 710. 

system 130 transmits merchant authorization request 315 to In function block 640, payment gateway computer system 

payment gateway system 140. 140 combines basic authorization response 710, and a copy 

of its signature public key certificate 720. Payment computer 

Payment Authorization Request Processing system 140 calculates a digital signature 725 for the com- 

FIG 6 depicts the detailed steps of processing a payment 30 bined contents of the combined block 730 comprising basic 

authorization request and generating and transmitting a authorization response 710 and the signature public key 

payment authorization request response. Function blocks certificate 720, and appends the signature to the combination 

610 through 630 depict the steps of processing a payment of the combined basic authonzahon response 710 and the 

authorization request, while function blocks 635 through 35 signature public key certificate .720. The payment gateway 

685 depict the steps of generating and transmitting a pay- computer system calculates digital signature 725 by first 

ment authorization request response. calculating a message digest based on the contents of the 

\ *, L t t «n , , 1bfCVCtpm combined bas c authorization response 710 and signature 

In function .block 610 payment ^y^P^"^ pub l ic key certificate 720. The message digest is then 

140 applies its private key to encrypted random key 560 P ^ fc mcM ter s tem * s 140 dlgital 

contained within received merchant authorization request « ^ * J > 

315, thereby decrypting it and obtaining a cieartext version signature pnvaic Key, 10 g s * 

of random key RK-0 540. In function block 615, payment FIG. 7B depicts the combined block 730 formed in 

gateway computer system 140 applies random key RK-0 function block 640 and containing basic authoazation 

540 to encrypted combined block 550, thereby decrypting it response 710, the signature public key certificate 720, and 

and obtaining a cieartext version of combined block 530. 45 digital signature 725. 

Combined block 530 comprises basic authorization request In function block 645, payment gateway computer system 

510 a copy of merchant computer system's 130 encryption 150 generates a first symmetric random encryption key 740, 

public key certificate 515 and a copy of merchant computer denoted as RK-1. FIG. 7C depicts first random encryption 

system's 130 signature public key certificate 520, as well as key RK-1 740. 

merchant digital signature 525. 5 o In function block 650, payment gateway computer system 

In function block 620, payment gateway computer system 140 encrypts combined block 730 using random encryption 

140 verifies merchant computer system's 130 encryption key RK-1 740 to form encrypted combined block 750. FIG. 

public key certificate 515 and merchant computer system's 7D depicts encrypted combined block 750. The encryption 

130 signature public key certificate 520. Payment gateway state of encrypted combined block 750 is graphically shown 

computer system 140 performs this verification by making a 55 by random key lock 755, which indicates that encrypted 

call to the certification authorities associated with each combined block 750 is encrypted using random key RK-1 

certificate. If verification of either certificate fails, payment 740. 

gateway computer system 140 rejects the authorization In function block 655, payment gateway computer system 

request. 140 encrypts random encryption key RK-1 740 using the 

In function block 625, payment gateway computer system 60 public key of merchant computer system 130 to form 

140 validates merchant digital signature 525. Payment gate- encrypted random key RK 760. FIG. 7E depicts encrypted 

way computer system 140 performs this validation by cal- random key RK-1 760. The encryption state of encrypted 

culating a message digest over the contents of the combined random key 760 is graphically shown by merchant public 

basic authorization request 510, the encryption public key key lock 765, which indicates that encrypted random key 

certificate 515 and the signature public key certificate 520. 65 760 is encrypted using the merchant public key. 

Payment gateway computer system 140 then decrypts digital In function block 660, payment gateway computer system 

signature 525 to obtain a copy of the equivalent message 140 generates a random capture token 770. Random capture 
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token 770 is utilized in subsequent payment capture pro- message digests are equal, the digital signature 725 is 

cessing to associate the payment capture request with the validated. If validation fails, concludes that the authorization 

payment authorization request being processed. FIG. 7F response is counterfeit and treats it though the authorization 

depicts capture token 775. request had been rejected. 

In function block 665, payment gateway computer system 5 In function block 850, merchant computer system 130 

140 generates a second symmetric random encryption key stores encrypted capture token 780 and encrypted random 

775, denoted as RK-2. FIG. 7G depicts second random key RK-2 790 for later use in payment capture. In function 

encryption key RK-2 775. block 860, merchant computer system 130 processes the 

In function block 670, payment gateway computer system n customer purchase request in accordance with the authori- 

140 encrypts capture token 770 using random encryption 10 nation response 710 If the authorization response indicates 

key RK-2 770 to form encrypted capture token 780. FIG. 7H that payment in authonzed merchant computer system 130 

depicts encrypted capture token 780. Tne encryption state of ™s the requested order. If the authorization response indi- 

encrypted capture token 780 is graphically shown by ran- cates that payment is not authonzed, or if merchant com- 

dom key lock 785, which indicates that encrypted capture c putcr system 130 determined in function block 830 or 840 

token 780 is encrypted using random key RK-2 770. 15 that the authorization response is counterfeit, merchant 

. „ . , , mm . , . computer system 130 indicates to the customer that the order 

In function block 675, payment gateway computer system * ' , 

140 encrypts second random encryption key RK-2 775 using cann0 e 

its own public key to form encrypted random key RK-2 790. Payment Capture 
FIG. 71 depicts encrypted random key RK-2 790. The n 

encryption state of encrypted random key 790 is graphically FIG. 9 depicts an overview of the method of securely 

shown by payment gateway public key lock 795, which supplying payment capture information to payment gateway 

indicates that encrypted random key 790 is encrypted using 140 in order to obtain payment capture. In function block 

the payment gateway public key. W>> merchant computer system 130 generates a merchant 

Infunctionblock680 )P aymentga«ewaycomputersystem 25 P^ ent ca P ture re ^ est ™^ l^VXv^v 

140 concatenates encrypted combined block 750, encrypted gateway co„^ 

random key RK-1 760, encrypted capture token 780 and ™* 8**™/ system 140 processes the payment capture 

encrypted random key RK-2 790 to form merchant autho- 915 generates a payment capture response 925 nd 

rizaZ response 325 FIG. 7J depicts merchant authoriza- * *> ™«* aQt «"JP ttter ^J^^^ 

♦ a />nmki'nfl^ kwv block 920, merchant computer system 130 processes pay- 

tion response 325 comprising encrypted combined block 30 UA ' / , -K ae . t u nt Jl*,™™, f^rthn 

750, encrypted random key RK-1 760, encrypted capture ment capture response 925 and verifies ^ ^ 

token 780 and encrypted random key RK-2 790. In function f^sor services sought to be obtained by the customer 

block 685, payment gateway computer system 140 transmits have been ca P mred - 

merchant authorization response 325 to merchant system Payment Capture Request Generation 

130. 35 „ 

FIG. 10 depicts the detailed steps of generating and 
Payment Authorization Response Processing transmitting a payment capture request FIGS. 11A through 
FIG. 8 depicts the detailed steps of processing a payment HF ^pict views of the payment capture request and its 
authorization response. In function block 810, merchant component parts. In function block 1010, merchant corn- 
computer system 130 applies its private key to encrypted 40 P uter system 130 creates a basic capture request 510 The 
random key RK-1 760 contained within received merchant basic capture request is a data area that includes all the 
authorization response 325, thereby decrypting it and information needed by payment gateway computer system 
obtaining a cleartext version of random key RK-1 740. In 1« to trigger a transfer of funds to the merchant operating 
function block 820, merchant computer system 130 applies merchant computer system 130. 

random key RK-1 740 to encrypted combined block 750, 45 Specifically, a capture request includes a capture request 

thereby decrypting it and obtaining a cleartext version of amount, a capture token, a date, summary information of the 

combined block 730. Combined block 730 comprises basic purchased items and a Merchant ID (MID) for the particular 

authorization response 710, a copy of payment gateway merchant. FIG. 11A depicts basic authorization request 

computer system's 140 signature public key certificate 720, 1110. 

as well as payment gateway digital signature 725. In func- 50 In function block 1020, merchant computer system 130 

tion block 830, merchant computer system 130 verifies combines basic capture request 1U0, a copy of its encryp- 

payment gateway computer system's 140 signature public tion public key certificate 1115 and a copy of its signature 

key certificate 720. Merchant computer system 130 per- public key certificate 1120. Merchant computer system 130 

forms this verification by making a call to the certification calculates a digital signature 1125 for the combined contents 

authority associated with the certificate. If verification of the 55 of the combined block 1130 comprising basic capture 

certificate fails, merchant computer system 130 concludes request 1110, the encryption public key certificate 1115 and 

that the authorization response is counterfeit and treats it the signature public key certificate 1120, and appends it to 

though the authorization request had been rejected. the combination of the combined basic capture request 1110, 

In function block 840, merchant computer system 130 the encryption public key certificate 1115 and the signature 

validates payment gateway digital signature 725. Merchant 60 public key certificate 1120. The merchant computer system 

computer system 130 performs this validation by calculating calculates digital signature 1125 by first calculating a mes- 

a message digest over the contents of the combined basic sage digest over the contents of the combined basic capture 

authorization request 710 and the signature public key request 1110, the encryption public key certificate 1115 and 

certificate 720. Merchant computer system 130 then the signature pubbc key certificate 1120. The message digest 

decrypts digital signature 725 to obtain a copy of the 65 is then encrypted using the merchant computer system's 130 

equivalent message digest calculated by payment gateway digital signature private key, thus forming a digital signa- 

computer system 140 in function block 640. If the two ture. 
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FIG. 11B depicts the combined block 1130 formed by gateway computer system 140 performs this validation by 

function block 1020 and containing basic capture request calculating a message digest over the contents of the com- 

1110, the encryption public key certificate 1115, the signa- bined basic capture request 1110, the encryption public key 

ture public key certificate 1120, and digital signature 1125. certificate 1115 and the signature public key certificate 1120. 

In function block 1030, merchant computer system 120 5 Payment gateway computer system 140 then decrypts digital 

generates a random encryption key 1140, denoted as RK-3. signature 1125 to obtain a copy of the equivalent message 

Random encryption key RK-3 1140 is a symmetric encryp- digest calculated by merchant computer system 130 in 

tion key. FIG. 11C depicts random encryption key RK-3 function block 1020. If the two message digests are equal, 

1140. In function block 1040, merchant computer system the digital signature 1125 is validated. If validation fails, 

130 encrypts combined block 1130 using random encryption 10 payment gateway computer system 140 rejects the capture 

key RK-3 1140 to form encrypted combined block 1150. request. In function block 1230, payment gateway computer 

FIG. 11D depicts encrypted combined block 1150. The system 140 applies its private key to encrypted random key 

encryption state of encrypted combined block 1150 is RK-2 790 contained within received merchant capture 

graphically shown by random key lock 1155, which indi- request 915, thereby decrypting it and obtaining a cleartext 

cates that encrypted combined block 1150 is encrypted using 15 version of random key RK-2 775. In function block 1235, 

random key RK-3 1140. In function block 1050, merchant payment gateway computer system 140 applies random key 

computer system 130 encrypts random encryption key RK-3 RK-2 775 to encrypted capture token 780, thereby decrypt- 

1140 using the public key of payment gateway system 140 ing it and obtaining a cleartext version of capture token 770. 

to form encrypted random key 1160. FIG. HE depicts In function block 1240, payment gateway computer sys- 

encrypted random key 1160. The encryption state of 20 tem 140 verifies that a proper transaction is being transmit- 

encrypted random key 1160 is graphically shown by pay- ted between capture token 780 and capture request 1110. A 

ment gateway public key lock 1165, which indicates that capture token contains data that the gateway generates at the 

encrypted random key RK-3 1160 is encrypted using the time of authorization. When the authorization is approved, 

payment gateway public key. the encrypted capture token is given to the merchant for 

In function block 1060, merchant computer system 130 25 storage. At the time of capture, the merchant returns the 
concatenates encrypted combined block 1150, encrypted capture token to the gateway along with other intormation 
random key 1160, and the encrypted capture token 780 and required for capture. Upon receipt of the capture token, the 
encrypted random key RK-2 790 that were stored in function gateway compares a message made of the capture request 
block 850 to form merchant capture request 915. FIG. UF data and the capture token data and transmits this informa- 
depicts merchant capture request 915, comprising encrypted 30 tion over a traditional credit/debit network. If an improperly 
combined block 1150, encrypted random key 1160, formatted transaction is detected, payment gateway corn- 
encrypted capture token 780 and encrypted random key puter system 140 rejects the capture request. In function 
RK-2 790. In function block 1070, merchant computer block 1245, payment gateway computer system 140 deter- 
system 130 transmits merchant capture request 915 to pay- mines the financial institution for which capture is requested 
ment gateway system 140. 35 *V inspection of basic capture request 1110. Payment gate- 
way computer system 140 contacts the appropriate financial 
Payment Capture Request Processing institution using a secure means, e.g, a direct-dial modem- 

FIG. 12 depicts the detailed steps of processing a payment to-modem connection, or a proprietary internal network that 
capture request and generating and transmitting a payment is no t accessible to third parties, and using prior art means, 
capture request response. Function blocks 1210 through 40 instructs a computer at the financial institution to perform 
1245 depict the steps of processing a payment capture the requested funds transfer after settlement, 
request, while function blocks 1250 through 1285 depict the p c ^ GcneratioD 
steps of generating and transmitting a payment capture J r L j • u f 
request response. In function block 1210, payment gateway Function blocks 1250 through 1285 depict the steps ot 
computer system 140 applies its private key to encrypted 45 generating and transmitting a payment capture request 
random key 1160 contained within received merchant cap- response. FIGS. 13A through 13F depict views of the 
ture request 915, thereby decrypting it and obtaining a payment capture response and its component parts, 
cleartext version of random key RK-3 1140. In function In function block 1250, payment gateway computer sys- 
block 1215, payment gateway computer system 140 applies tem 140 creates a basic capture response 710. The basic 
random key RK-3 1140 to encrypted combined block 1150, 50 capture request is a data area that includes all the informa- 
thereby decrypting it and obtaining a cleartext version of tion to indicate whether a capture request was granted or 
combined block 1130. Combined block 1130 comprises denied. FIG. 13A depicts basic authorization request 1310. 
basic capture request 1110, a copy of merchant computer In function block 1255, payment gateway computer sys- 
system's 130 encryption public key certificate 1115 and a tem 140 combines basic capture response 1310, and a copy 
copy of merchant computer system's 130 signature public 55 of its signature public key certificate 1320. Payment corn- 
key certificate 1120, as well as merchant digital signature puter system 140 calculates a digital signature 1325 for the 
1125. In function block 1220, payment gateway computer combined contents of the combined block 1330 comprising 
system 140 verifies merchant computer system's 130 basic capture response 1310 and the signature public key 
encryption public key certificate 1115 and merchant com- certificate 1320, and appends the signature to the combina- 
puter system's 130 signature public key certificate 1120. 60 tion of the combined basic authorization request 1310 and 
Payment gateway computer system 140 performs this veri- the signature public key certificate 1320. The payment 
fication by making a call to the certification authorities gateway computer system calculates digital signature 1325 
associated with each certificate. If verification of either by first calculating a message digest over the contents of the 
certificate fails, payment gateway computer system 140 combined basic capture response 1310 and signature public 
rejects the capture request. 65 key certificate 720. The message digest is then encrypted 

In function block 1225, payment gateway computer sys- using the merchant computer system's 140 digital signature 

tem 140 validates merchant digital signature 1125. Payment private key, thus forming a digital signature. 
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FIG. 13B depicts the combined block 1330 formed by 
function block 1255 and containing basic capture request 
1310, the signature public key certificate 1320, and digital 
signature 1325. Id function block 1260, payment gateway 
computer system 140 generates a symmetric random encryp- 5 
tion key 1340, denoted as RK-4. FIG. 13C depicts random 
encryption key RK-4 1340. In function block 1275, payment 
gateway computer system 140 encrypts combined block 
1330 using random encryption key RK-4 1340 to form 
encrypted combined block 1350. FIG. 13D depicts 10 
encrypted combined block 1350. The encryption state of 
encrypted combined block 1350 is graphically shown by 
random key lock 1355, which indicates that encrypted 
combined block 1350 is encrypted using random key RK-4 
1340. In function block 1275, payment gateway computer 15 
system 140 encrypts random encryption key RK-4 1340 
using the public key of merchant computer system 130 to 
form encrypted random key RK-4 1360. FIG. 13E depicts 
encrypted random key RK-4 1360. The encryption state of 
encrypted random key 1360 is graphically shown by mer- 20 
chant public key lock 1365, which indicates that encrypted 
random key 1360 is encrypted using the merchant public 
key. In function block 1280, payment gateway computer 
system 140 concatenates encrypted combined block 1350 
and encrypted random key RK-4 1360 to form merchant 25 
capture response 925. FIG. 13F depicts merchant capture 
response 925 comprising encrypted combined block 1350 
and encrypted random key RK-4 1360. In function block 
1285, payment gateway computer system 140 transmits 
merchant capture response 925 to merchant system 130, 30 

Payment Capture Response Processing 
FIG. 14 depicts the detailed steps of processing a payment 
capture response. In function block 1410, merchant com- 
puter system 130 applies its private key to encrypted random 35 
key RK-4 1360 contained within received merchant capture 
response 925, thereby decrypting it and obtaining a cleartext 
version of random key RK-4 1340. In function block 1420, 
merchant computer system 130 applies random key RK-4 
1340 to encrypted combined block 1350, thereby decrypting 40 
it and obtaining a cleartext version of combined block 1330. 
Combined block 1330 comprises basic capture response 
1310, a copy of payment gateway computer system's 140 
signature public key certificate 1320, as well as payment 
gateway digital signature 1325. In function block 1430, 45 
merchant computer system 130 verifies payment gateway 
computer system's 140 signature public key certificate 1320. 
Merchant computer system 130 performs this verification by 
making a call to the certification authority associated with 
the certificate. If verification of the certificate fails, merchant 50 
computer system 130 concludes that the capture response is 
counterfeit and raises an error condition. 

In function block 1440, merchant computer system 130 
validates payment gateway digital signature 1325. Merchant 
computer system 130 performs this validation by calculating 55 
a message digest over the contents of the combined basic 
authorization request 1310 and the signature public key 
certificate 1320. Merchant computer system 130 then 
decrypts digital signature 1325 to obtain a copy of the 
equivalent message digest calculated by payment gateway 60 
computer system 140 in function block 1255. If the two 
message digests are equal, the digital signature 1325 is 
validated. If validation fails, merchant computer system 130 
concludes that the authorization response is counterfeit and 
raises an error condition. In function block 1450, merchant 65 
computer system 130 stores capture response for later use in 
by legacy system accounting programs, e.g. to perform 



reconciliation between the merchant operating merchant 
computer system 130 and the financial institution from 
whom payment was requested, thereby completing the trans- 
action. The system of the present invention permits imme- 
diate deployment of a secure payment technology architec- 
ture such as the SET architecture without first establishing a 
public-key encryption infrastructure for use by consumers. It 
thereby permits immediate use of SET-compliant transaction 
processing without the need for consumers to migrate to 
SET-compliant application software. 

Virtual Point of Sale (VPOS) Details 
A Virtual Point of Sale (VPOS) Terminal Cartridge is 
described in accordance with a preferred embodiment. The 
VPOS Terminal Cartridge provides payment functionality 
similar to what a VeriFone PoS terminal ("gray box") 
provides for a merchant today, allowing a merchant to 
process payments securely using the Internet. It provides full 
payment functionality for a variety of payment instruments. 

Payment Functionality 
FIG. 15 A illustrates a payment processing flow in accor- 
dance with a preferred embodiment. The payment function- 
ality provided by the VPOS terminal is divided into two 
main categories: "Merchant-Initiated" 1510 and 
"Consumer-Initiated" 1500. Some payment transactions 
require communication with the acquirer bank through the 
Gateway 1530. The normal flow of a transaction is via the 
VPOS Cartridge API 1512 to the VPOS C++ API 1514 into 
the payment protocol layer 1516 which is responsible for 
converting into the appropriate format for transmission to 
the Gateway for additional processing and forwarding to 
existing host payment authorization systems. Host legacy 
format refers to an existing authorization system for credit 
card approval currently utilized with the VeriFone Point of 
Sale (POS) gray terminals. The output from the payment 
protocol layer 1516 is transmitted to the authorization pro- 
cessing center via the gateway 1530. These transactions are 
referred to as "Online Transactions" or "Host Payments." 
The transactions that can be done locally by the merchant 
without having to communicate with the acquirer bank are 
referred to as "Local Functions and Transactions." To sup- 
port different types of payment instruments, the VPOS 
Terminal payment functionality is categorized as set forth 
below. 

Host Payment Functionality: These transactions require 
communication with the final host, either immediately 
or at a later stage. For example, an Online 
Authorization-Only transaction, when initiated, com- 
municates with the host immediately. However, an 
Off-line Authorization-Only transaction is locally 
authorized by the VPOS terminal without having to 
communicate with the host, but at a later stage this 
off-line authorization transaction is sent to the host. 
Within the Host Payment Functionality some transac- 
tions have an associated Payment Instrument, while 
others do not. These two kinds of transactions are: 

Host Financial Payment Functionality: These transactions 
have a Payment Instrument (Credit Card, Debit Card, 
E-Cash, E-Check, etc.) associated with them. For 
example, the "Return" transaction, which is initiated 
upon returning a merchandise to the merchant. 

Host Administrative Payment Functionality: These trans- 
actions do not require a payment instrument, and pro- 
vide either administrative or inquiry functionality. 
Examples of these transactions are "Reconcile" or the 
"Batch Close." 
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Local Functions and Transactions: These transactions do 
not require communication with the host at any stage, 
and provide essential VPOS terminal administrative 
functionality. An example of this is the VPOS terminal 
configuration function, which is required to set up the 
VPOS terminal Another example is the "VPOS Batch 
Review** function, which is required to review the 
different transactions in the VPOS Batch or the Trans- 
action Log. 
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in the HTML document that is returned by the VPOS 
Terminal Cartridge: 



txnDate 
txnTime 



Date of the transaction (mm/dd/yy or dd/mm/yy) . 
Time of the transaction (hh:mm:ss GMT or hh:mm:ss local 
time) 

merchantld Merchant ID of the merchant using the VPOS terminal 
tcrminalld VPOS Terminal Id 

txnNum Transaction number of the given transaction 
txnType Type of transaction 



Payment Instruments 

A preferred embodiment of a VPOS terminal supports 
various Payment Instruments. A consumer chooses a pay- 
ment based on personal preferences. Some of the Payment 
Instruments supported include: 

Credit Cards 
Debit Cards 
Electronic Cash 
Electronic Checks 
Micro-Payments (electronic coin) 
Smart Cards 



LOCAL FUNCTIONS & TRANSACTIONS 



accum review 


/VPOSt/mi/accum/revi 


not allowed 


merchant 




ew/ 




login/password 


batch review 


WOSt/mi/batch/revie 


not allowed 


merchant 




w/ 




login/password 


cdt review 


/VPOSt/mi/cdt/review/ 


not allowed 


merchant 








login/password 


cdt update 


/VPOSt/mi/cd [/update 


allowed 


merchant 


/ 




login/password 


cpt review 


/VPOSt/mi/cpt/review 


not allowed 


merchant 






login/password 


cpt update 


/VPOSt/mi/cpt/updatc 


allowed 


merchant 


/ 




login/password 


clear accum 


/VPOSt/accum/dear/ 


allowed 


merchant 








login/password 


clear batch 


/VPOSt/m i/batch/clear 


allowed 


merchant 




/ 




login/password 


hdt review 


/VPOSt/m i/hdt/rev iew 


not allowed 


merchant 




/ 




login/password 


hdt update 


/VPOSi/mi/hdt/update 


allowed 


merchant 


/ 




login/password 


lock VPOS 


/VPOSt/mi/loclt/ 


allowed 


merchant 








login/password 


query Din 


/VPOSl/ci/querytxn/ 


not allowed 


no access control 


query txn 


/VPOSt/m i/que rytxn/ 


not allowed 


merchant 






login/password 


tct review 


/VPOSt/m i/tct/revie w/ 


not allowed 


merchant 








login/password 


let update 


/VPOSt/mi/tct/update 


allowed 


merchant 


/ 




login/password 


unlock VPOS 


/VPOSt/miAinlock/ 


allowed 


merchant 








login/password 



For URLs that deal with financial transactions, the fol- 
lowing fields are present in the HTML document that is 
is returned by the VPOS terminal cartridge: 



txnAmount Transaction amount that is being authorized, forced 

posted, voided, etc 
po Number Purchase order number 
authldentNu Authorization ID number for the transaction 
m 

retReENum Retrieval reference number for the given transaction 
pilnfo Payment instrument information. This varies for different 

payment instruments. For example, in the case of credit 
cards, the credit card number (piAcctNumber) and 
25 expiration date (piExpDate) are returned. 



Accumulate Review 

URL Functionality: This is a local information inquiry 
function that retrieves the local (merchant's) transaction 
totals (accumulators). 

GET Arguments: None. 

GET Results: Retrieves the transaction totals for the 
merchant. Currently, the total is returned as an HTML 
document. The transaction totals currently returned are: 



creditAmt Total Credit Amount since the last settlement logged in the 
VPOS terminal 

40 creditCnt Total Credit Count since the last settlement logged in the 
VPOS terminal 

debitAmt Total Debit Amount since the last settlement logged in the 
VPOS terminal 

debitCnt Total Debit Count since the last settlement logged in the 
VPOS terminal 

45 ^ ; 

Note: Accum Review is a local function, as opposed to Balance Inquiry 
which is done over the Internet with the host. 

Adjust 

50 URL Functionality: Corrects the amount of a previously 
completed transaction. 
GET Arguments: None 

GET Results: Because the Adjust transaction modifies 
data on the merchant server the POST method should be 
55 used. Using the GET method returns an HTML form that 
uses the POST method to perform the transaction. 

POST Arguments: 



URL Descriptions 



60 pvsTxnNum Previous transaction number 

txnAdjustedAmou The adjusted transaction amount. Note that the original 
nt transaction amount is easily retrievable from the 

previous transaction number. 



This section describes the GET and POST arguments that 
are associated with each transaction URL. It also describes 65 
the results from the GET and POST methods. For URLs that 
produce any kind of results, the following fields are present 



POST Results: On success, pvsTxnNum and txnAdjust- 
edAmount are presented in the HTML document, in addition 
to the transaction fields described above. 
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URL Functionality: This transaction is a combination of 
Auth Only (Authorization without capture) and Forced Post 
transactions. 

GET Arguments: None 

GET Results: Because the Auth Capture transaction modi- 
fies data on the merchant server side, the POST method 
should be used. Using the GET method returns an HTML 
form that uses the POST method to perform the transaction. 

POST Arguments: 



piAcctNumbcr Payment Instrument account number, e.g., Visa credit 

card number 
piExpDate Expiration date 
txoAmt Transaction amount 



POST Results: On success, an HTML document that 
contains the transaction fields described above is returned. 
On failure, an HTML document that contains the reason for 
the failure of the transaction is returned. The transaction is 
logged into a VPOS Terminal transaction log for both 
instances. 

Auth Only 

URL Functionality: Validates the cardholder's account 
number for a Sale that is performed at a later stage. The 
transaction does not confirm the sale to the host, and there 
is no host data capture. The VPOS captures this transaction 
record and later forwards it to confirm the sale in the Forced 
Post transaction request. 

GET Arguments: None. 

GET Results: Because the Auth Only transaction modifies 
data on the merchant server side, the POST method should 
be used. Using the GET method returns an HTML form that 
uses the POST method to perform the transaction. 

POST Arguments: 



piAcctNumbcr Payment Instrument account number, e.g., Visa credit 

card number 
piExpDate Expiration date 
txnAmt Transaction amount 



mrchlBlnceA Merchant balance amount for a given merchant. The 

m t balance amount at any given time is the difference between 

the credit and debit amount since the last settlement 

between the merchant and the acquirer. 
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Batch Review 



URL Functionality: Retrieves all records from the trans- 
action log or the batch. 
GET Arguments: None 

15 GET Results: The GET method retrieves the transactions 
that have been batched in the VPOS terminal for future 
reconciliation. The batch can be cleared from the VPOS 
terminal after a manual reconciliation between the acquirer 
and the VPOS. The batch data is retrieved as a set of records 

20 and is formatted as a table in the HTML document. The 
following fields are present in a typical record: 
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nTransType Transaction type 

nPurchOrdciNo Purchase order number 

szAcctNum Customer's payment instrument account number 

szExpDate Customer's payment instrument expiration date 

szTransAmt Transaction amount 

szTransDate Transaction date 

szTransTunc Transaction time 

3° szRetrievalRefNu Transaction's retrieval reference number 
m 

szAuthld Authorization ID for the transaction 

szOrigAmt Original transaction amount 

szBatchNurn Batch number for the given transaction 

nCurrencyType Currency in which the transaction was done 

35 InTransNum Transaction number 



URL Functionality: Displays the VPOS terminal configu- 
ration data corresponding to the Card Definition Table 
(CDT). 

GET Arguments: None 
GET Results: The GET method returns a default HTML 
form that contains the current configuration values. The 
form can be modified and posted using the /VPOSt/mi/cdt/ 
45 update/ URL to update the card definition table. Not all fields 
in the card definition table are editable. The following fields 
are returned in a form to the user: 



40 
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POST Results: On success, an HTML document that 
contains the transaction fields is returned. On failure, an 
HTML document that contains the reason for the failure of 
the transaction is returned. The transaction is logged into 
VPOS Terminal transaction log for both instances. 

NOTE: The /VPOSt/ci/authonly/ URL should be used for 
customer-initiated transactions. /VPOSt/mi/authonly/ 
should be used for merchant- initiated transactions. 

Balance Inquiry 

URL Functionality: Performs an on-line inquiry or the 
merchant's balance. 

GET Arguments: None 



nHostludex Index into the Host Definition Table or the acquirer 

that maps to this card issuer. 
szPANLo Low end of the PAN (Primary Account Number) range 

szPANHi High end of the PAN range 

nMaxPANDigit Maximum number of digits in the PAN for this 
acquirer. 

55 NMinPANDigit Minimum number of dits in the PAN for the acquirer 
szCard Label Card Issuer's name 

Transactions Specifies if a particular transaction is allowed for a 

Available bit given card range. 

vector 



60 



65 



(Some of these fields are not editable by a merchant, and still 
need to be determined.) 

CDT Update 

URL Functionality: Updates the VPOS terminal configu- 
ration data corresponding to the Card Definition Table 
(CDT). 
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GET Arguments: None 

GET Results: The GET method returns a default HTML 
form that contains the current configuration values. The 
form can be filled out and posted using the /VPOSt/mi/cdt/ 
update URL to update the card definition table. 

POST Arguments: (Editable CDT fields need to be 
decided.) 

POST Results: (Depends on editable CDT fields, and 
therefore needs to be decided.) 

Clear Accumulator 

URL Functionality: Zeroes out the accumulator totals 
currently resident in the VPOS terminal. 

GET Arguments: None. 

GET Results: Presents a form that uses the POST method 
to zero the accumulators. 

POST Arguments: None. 

POST Results: Zeroes the accumulators/transaction totals 
in the VPOS terminal. 

Clear Batch 

URL Functionality: Zeroes out the transaction logs cur- 
rently batched in the VPOS terminal. 

GET Arguments: None. 

GET Results: Presents a form that uses the POST method 
to clear the batch. 

POST Arguments: None. 



10 



fields in the host definition table are editable. The following 
fields are returned in a form to the user: 



szTermld Terminal ID for this VPOS terminal 

szMerchld Merchant tD for this VPOS terminal 
szCurrBatchNu Current batch number existing on the VPOS 
m 

szTransNum Reference number for the next transaction in the VPOS 
transaction log/batch. This is generated by VPOS and is 
not editable by the merchant. 

Transport Protocol Data Unit. Required for building the 
ISO 8583 packet. 

System trace number, message number of the next 
transaction to be transmitted to this acquirer. 
Network International Number. Required for building the 
ISO 8583 packet. 
Name foi identifying the host. 
Host type 

Number of off-line transactions that can be piggy-backed 
at the end of an on-line transaction. 
Specifies for which transactions data capture is 
required. 





szTPDU 




InSTAN 




szNII 


15 






szHostName 




nHostType 




nNumAdv 




Data Capture 


20 


Required Bit 




vector: 



(Some of these fields are not editable by a merchant and 
need to be determined.) 

HDT Update 

URL Functionality: Updates the VPOS terminal configu- 
ration data corresponding to the Host Definition Table 
(HDT). 

GET Arguments: None 

GET Results: The GET method returns a default HTML 
POST Results: Zeroes the transactions that comprise the 35 form that contains the current configuration values The form 
batch in the VPOS terminal. can be filled out and posted to the merchant server using the 

/VPOSt/mi/hdt/update URL to update the host definition 
Forced Post table 

URL Functionality: Confirms to the host the completion 40 
of a sale, and requests for data capture of the transaction. 
This is used as a follow-up transaction after doing an 
Authorization (Online or Off-line) transaction. 

GET Arguments: None. 4S 
GET Results: Returns the HTML form for performing the 
Forced Post transaction. 

POST Arguments: 

pvsTxnNum the previous transaction number from an 50 
auth only transaction 

POST Results: On success, pvsTxnNum is presented in 
the HTML document. On failure, an HTML document is 
returned that contains the reason for the failure of the 
transaction. 55 

HDT Review 



URL Functionality: Displays the VPOS terminal configu- 
ration data corresponding to the Host Definition Table 60 
(HDT). 

GET Arguments: None 

GET Results: The GET method returns a default HTML 
form that contains the current configuration values. The 65 
form can be modified and posted using the /VPOSt/mi/hdt/ 
update URL to update the hosts definition table. Not all 



Unlock VPOS 

URL Functionality: Local function that starts the VPOS at 
the start of the day. 

GET Arguments: None. 

GET Results: Returns an HTML form that uses the POST 
method to perform this transaction. 

POST Arguments: None. 

POST Results: Resets a Boolean flag on the merchant 
server that enables transactions to be accepted by the VPOS 
terminal. 

Offline Auth 

URL Functionality: This transaction is same as the 
"Authorization Only" transaction, except that the transaction 
is locally captured by the VPOS terminal without having to 
communicate with the host. A Forced Post operation is done 
as a follow-up operation of this transaction. 

GET Arguments: None. 

GET Results: Because the Offline Auth transaction modi- 
fies data on the merchant server side, the POST method 
should be used. Using the GET method returns an HTML 
form for using the POST method to perform the transaction. 
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POST Arguments: Reconcile 

URL Functionality: This transaction is done at the end of 
the day to confirm to the host to start the settlement process 

piAcctNumber Payment Instrument account number, e.g., Visa credit , for the transactions captured by the host for that particular 
card number VPOS batch. 

piExpDatc Expiration date GET Arguments: None 

txnAmt Transaction amount . 
GET Results: Retrieves the HTML form for posting the 

Reconcile transaction. 

POST Results: On success, an HTML document that 1Q pQST A| ^ nls: None< 
contains the transacUon fields J^^ 1 * POST Results: On success, the reconcile function prints 

returned. On far ure, an HTML document that- contauis to discrepancies in me merchant > s balch of transactions 

reason for the failure ^^^^.^T^^ and totals vis-a-vis the host's batch of transactions in totals. 
transacUon is logged into VPOS terminal transaction log for ^ ^ ^ fc & of ^ QUtput of the 

both instances. 15 Review and Accum Review transactions. 



Parameter Download 



Return 



URL Functionality: Downloads the VPOS configuration 

information from the host and sets up the VPOS in the event URL Functionality: Credits the return amount electroni- 

of the configuration data being changed. cally to the consumer's account when previously purchased 

GET Arguments: None merchandise is returned. The VPOS terminal captures the 

GET Results: Retrieves an HTML form that uses the transaction record for this transaction. 

POST method for the parameter download transaction. GET Arguments: None 

POST Arguments: None. GET Results: Retrieves the HTML form for posting the 

POST Results Downloads the following parameters from 25 Return transaction, 

the host and uploads them into the VPOS terminal configu- POST Arguments: 

ration table. prev/TxnNum Reference to the previous transaction num- 

card/issuer definition table (CDT) ber 

host/acquirer definition table (HDT) The previous transaction has access to the following fields: 

communications parameter table (CPT) 30 
terminal configuration table (TCT) 

The various configuration parameters can be reviewed and UnAm0UQt Transaction amount 

modified using the URLs for the desired functionality. piAccountNu Payment instrument account number 

Pre Auth 35 
URL Functionality: Used in lodging and hotel establish- 
ments to pre-authorize a charge that is completed some time p0ST ResuUs . Qn success> pvs TxnNum is presented in 

m future - the HTML document, in addition to 
GET Arguments: None 

GET Results: Retrieves the HTML form for posting the 40 Test Host 

pre-authorization transaction. }JKL Functionality: Checks the presence of the host and 

POST Arguments: also me integrity of the link from the VPOS to the host. 

GET Arguments: None. 

. 45 GET Results: On success, an HTML document is returned 

piAcctNumber Payment Instrument account number, e.g., Visa credit that reports success in connecting to the host. On failure, an 

card number HTML document is returned that reports the error encoun- 

piExpPate Expiration date ^ m testing ^ host 



piExpDate Payment instrument expiration date 



Pre Auth Comp 



50 Lock VPOS 



. , URL Functionality: This local function locks or stops the 

URL Functionality: Completes a pre-authorization trans- wos termina] ^ acce p lin g any transactions. 



action. 



GET Arguments: None. 

GET Arguments: None GET Results: Returns an HTML form that posts the 



GET Results: Retrieves the HTML form for posting the 55 
pre-authorization completion transaction 



locking of the VPOS terminal. 



pn „ TA POST Arguments: None. 

fUbl Arguments. pQST Resu[ts: Qn aa HTML document is 

returned that contains the status that VPOS terminal was 
60 successfully. On failure, an HTML document is returned that 

pvsTxnNum Previous transaction number from an auth only reports the cause of failure of the Operation, e.g., aCCCSS 

transaction denied, the VPOS terminal is already locked or is presently 

processing a transaction, etc. 
POST Results: On success, pvsTxnNum is presented in Vo - d 
the HTML document. On failure, an HTML document is 65 

returned that contains the reason for the failure of the URL Functionality: Cancels a previously completed draft 
transaction. capture transaction. 
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GET Arguments: None. 

GET Results: Retrieves an HTML form for posting the 
Void transaction. 
POST Arguments: 



pvsTxnNum 



Transaction number from a previous Auth Only 
transaction. 



Host Logon 

URL Functionality: Administrative transaction used to 
sign-on the VPOS with the host at the start of the day, and 
also to download encryption keys for debit transactions. 

GET Arguments: None 

GET Results: Retrieves an HTML form for posting the 
Host Logon transaction. 
POST Arguments: None. 

POST Results: Currently, debit card based transactions 
are not supported. The result is an HTML document indi- 
cating the success or failure of the host logon operation. 



CPT Review 



szAcqPriAddress Primary Host address 
szAcqSecAddress Secondary Host address 
SzAclTerAddress Tertiary Host address 

nRespTimeOut Time-out value (in seconds) before which the VPOS 
should receive a response from the host 
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10 



20 



25 



URL Functionality: Returns the VPOS terminal configu- 
ration data corresponding to the Communications Parameter 
Table (CPT). 

GET Arguments: None 30 
GET Results: The GET method returns a default HTML 
form that contains the current configuration values corre- 
sponding to the VPOS terrninars communication param- 
eters. The form can be filled out and posted to the merchant 
server using the /VPOS t/mi/cpt/upd ate URL to update the 35 
communications parameter table. The following fields are 
returned in a form to the user 



failure, the HTML document contains the reason for the 
failure of the invocation of the URL. 

TCT Review 

URL Functionality: Returns the VPOS terminal configu- 
ration data corresponding to the Terminal Configuration 
Table (TCT). 

GET Arguments: None. 

GET Results: The GET method returns a default HTML 
form that contains the current configuration values. The 
form can be rilled out and posted using the /VPOSt/mi/tct/ 
update URL to update the terminal configuration table. The 
following fields are returned in a form to the user: 



szMerchName Merchant name 

szSupervisorPwd Supervisor password 

fVPOSLock 1 - VPOS locked, 0 - VPOS unlocked 

szAuthOnlyPwd Password for initiating auth-only transaction 

BzAuthCaptPwd Password for initiating auth with capture transaction 

szAdjustPwd Password for adjust transaction 

szRefundPwd Password for refund transaction 

szForccdPostPwd Password for forced post transaction 

SzOfflineAuthPwd Password for offline auth transaction 

szVoidPwd Password for void transaction 

szPreAuthPwd Password for pre-authorization transaction 

szPreAuthCompP Password for pre-authorization completion 

wd 



40 



TCT Update 

URL Functionality: Updates the VPOS terminal configu- 
ration data corresponding to the Terminal Configuration 
Table (TCT). 

GET Arguments: None 

GET Results: The GET method returns a default HTML 
form that contains the current configuration values. The 
form can be filled out and posted using the /VPOSt/mi/tct/ 
update URL to update the terminal configuration table. 

POST Arguments: All arguments in TCT Review func- 
tionality are the returned values from the /VPOSt/mi/tct/ 
update the URL. 



45 



CPT Update 

URL Functionality: Updates the VPOS terminal configu- 
ration data corresponding to the Communications Parameter 
Table (CPT). 

GET Arguments: None 

GET Results: The GET method returns a default HTML 
form that contains the current configuration values. The 
form can be modified and posted to update the communi- 
cation parameter table. 

POST Arguments: 



szMerchName Merchant name 

szSupervisorPwd Supervisor password 

fVPOSLock 1 - VPOS locked, 0 - VPOS unlocked 

szAuthOnlyPwd Password for initiating auth-only transaction 

szAuthCaptPwd Password for initiating auth with capture transaction 

50 szAdjustPwd Password for adjust transaction 

szRefundPwd Password for refund transaction 

szFo reed Post Pwd Password for forced post transaction 

SzOfflineAuthPwd Password for offline auth transaction 

sz\bidPwd Password for void transaction 

szPreAuthPwd Password for pre-authorization transaction 

55 szPreAuthCompP Password for pre-authorization completion 
wd 



POST Results: On success, the POST modifies values of 
the terminal configuration table parameters. On failure, the 
60 HTML document contains the reason for the failure of the 
transaction. 

Query Transactions 



szAcqPriAddress Primary Host address 
szAcqSecAddress Secondary Host address 
szActTerAddress Tertiary Host address 

oRespTimeOut Time-out value (in seconds) before which the VPOS 
should receive a response from the host 

' 65 URL Functionality: Permits the merchant and customer to 

POST Results: On success, the HTML document returned query a given transaction corresponding to a transaction 

by the VPOS contains the values set by the merchant. On number. 
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GET Arguments: 

txnNum Transaction number 

GET Results: For a given transaction, the URL returns an 
HTML document. If a transaction refers to an older 
transaction, the transaction's entire history is made avail- 
able. 

URL Results 

Depending upon the method (GET/POST) as well as the 
success or failure of the HTTP request, different documents 
are returned to the user. The VPOS terminal provides a 
framework whereby different documents are returned based 
upon a number of preferences. Currently the language and 
content-type are supported as preferences. 

A simple framework is proposed here. Each of the trans- 
action has a set of documents associated with it: form for the 
payment transaction, GET success, GET failure, POST 
success, and POST failure. 

In the directory structure defined below, documents are 
stored corresponding to the preferences. The top level of the 
directory structure is the content-type, the next level is 
language (for NLS support). For example, to create text/html 
content in US English & French, the directory structure 
given below would contain the HTML documents for each 
of the transactions. The VPOS terminal cartridge has a 
configuration file that allows the user to specify the content- 
type as well as the language to be used for a cartridge. The 
first release of the VPOS terminal cartridge supports one 
content-type and language for each server. 

Data Structures & Functions 

A brief description of the Virtual Point of Sale Terminal 
cartridge functions are provided below. VPOSTInit( ), 
VPOSTExec( ) and VPOSTShut( ) are the entry points 
required for each cartridge in accordance with a preferred 
embodiment. The other functions implement some of the 
key VPOST cartridge functionality. A source listing of the 
VPOS code is provided below to further accentuate the 
detailed disclosure of a preferred embodiment. 



-continued 



WRBEnlry "WRBEntries; 

int numEntries; 
5 VPOSTCxp - (VPOSTCtx *) clientCtx; 

/* WRBGetURL gets the URL for the current request */ 

if (!(uri = WRBGetURL( WRBCtx ))) 
return (WRB__ERROR); 

/* WRBGetContentO gets the QueryString/POST data content */ 

if ([(txnConteat = WRBGetContent( WRBCtx ))) { 
10 return WRB_ERROR; 

/• WRBGetParserContcniO gets the parsed content */ 
if (WRB_ERROR — WRBGEtParsedContentf WRBCtx, 
&WRBEntries, & numEntries)) { 
return WRB __ERROR; 

15 /* WRBGetEnvironmentO gets the HTTP Server Environment V 
if (!(txnEnv - WRBGetEnvironment( WRBCtx ))) { 
return WRB„ERROR; 

^ /* VPOSTGctMcthodO gets the method for the current request 7 
if ('(method - VPOSTGetMethod( txnEnv ))) { 
20 return (WRB_ERROR); 

/* VPOSTGetTxnO gets the VPOST transaction for the request */ 
txn - VPOSTGetTxn( uri >, 
if (eTxnError = txn) { 

return (WRB_ERROR); 

25 } 

I* VPOSTExecuteTransactionO executes the VPOST transaction V 
txnOutFile = WOSTExecutcTransaction( WRBCtx, txn, txnMcthod, 

txnEnv, txnContent ); 
if (!(txnOutFUe)) { 

return (WRB_ERROR); 

30 } 

/* Write out the file 7 
VPOSTWriteFUe( txnOutFile ); 
return (WRB_DONE); 

^ VPOSTGetTxnO 
35 cnum cVPOSTTxn 

VPOSTGetTxn( char "uri ) 
{ 

/* 

* The function scans the uri and extracts the string 
■ corresponding to the transaction and returns it to the 



VPOSTEnitO 
/* VPOST cartridge Initialization here 7 
WRBReturnCode 
VPOSTInit( void "clientCtx ){ 
VPOSTCtx *VPOSTCxp; 
/* Allocate memory for the client context 7 
if (t(VPOSTCxp = (VPOSTCtx ") ma lloc(sizeof (VPOSTCtx)))) 
return WRB_ERROR; 
•clientCtx = (void *) VPOSTCxp; 
return (WRB_DONE) ;} 

VPOSTShutO 

WRBReturnCode 

VPOSTShut( void "WRBCtx, void 'clientCtx) { 
•WRBCtx; /• not used 7 
assert( clientCtx ); 

r Free the client context allocated in VPOSTInitO routine 
free( clientCtx ): 
return (WRB_DONE) ;} 
VPOSTExecO 

/* The driver cartridge routine 7 
WRBReturnCode 

VPOSTExec( void 'WRBCtx, void 'clientCtx ) 
{ 

VPOSTCtx 'VPOSTCxp; 

char *uri; 

char •txnMethod; /• HTTP method 7 
enum eVPOSTTxn *txn; /* VPOST transaction 7 
char ■txnOutFdc ; /' Output file from transaction 7 
char **txnEnv; /* environment variables values for transaction */ 
char *txnContent; /* transaction's POST data content •/ 



Transaction Log Format 

45 

This section describes the format of a record for the 
transaction log for the VPOST cartridge. 
Field Name Field Description 



50 



55 



60 



nTransType 


Transaction Type 


nPurchOrderNo 


Purchase Order Number 


szAcctNum 


Payment Instrument Account number 


szExpDate 


Payment instrument expiration date 


szTransAmt 


Transaction amount 


szTransDate 


Date of transaction (configurable to be mm/dd/yy 




or dd/mnVyy) 


szTransTune 


Time of transaction (configurable to be GMT or 




local time) 


szRetrieval RefNum 


Retrieval reference cumber 


szAuthld 


Authorization ID 


szOrigAmt 


Original transaction amount 


szBatchNum 


Batch number to which this particular transaction 




belongs in the VPOST batch 


nCunencyType 


Currency 


InTransNum 


Transaction number 



65 

In the block diagram shown in FIG. 15B, the VPOS provides 
an interface for transactions which are initiated both by the 
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consumer and the merchant. The merchant initiates a trans- 
action from a Graphical User Interface (GUI) 1550 and all 
the transactions that are initiated by the consumer are routed 
by the Merchant WEB Server 1545. 

The Authorization/Data Capture Module 1560 processes 5 
the requests originated by the merchant or the consumer and 
routes them to the Protocol Module 1565. The Protocol 
Module is responsible for building the payment protocol 
request packet (e.g., an SSL-encapsulated ISO 8583 packet) 
1570 before sending the request to the Gateway 1579. Then, 10 
the Gateway 1579 awaits a response from the Protocol 
Module 1565, and upon receiving the response, the Gateway 
1579 parses the data and provides unwrapped data to the 
Authorization/Data-Capture Module 1560. The 
Authorization/Data-Capture Module 1560 analyzes the 15 
response and updates the Transaction Log 1580. The Trans- 
action Log 1580 contains information concerning any suc- 
cessfully completed transactions and the accumulators or the 
transaction totals. The VPOS terminal creates and maintains 
the Transaction Log 1580, and the VPOS Configuration Data 20 
1585 contains information which is used to configure the 
behavior of the VPOS. The entire VPOS functionality is 
thread-safe and hence using the VPOS in a multi-threaded 
environment does not require any additional interfacing 
requirements. 25 

FIGS. 36-48 are VPOS screen displays in accordance 
with a preferred embodiment. 

Payment Functionality 

As discussed above, the different Payment Functionality 3Q 
provided by the VPOS terminal Can be divided into two 
main categories as "Merchant Initiated" and "Consumer 
Initiated." Some of these transactions require communica- 
tion with the Gateway and these transactions are referred to 
as "Online Transactions/* The transactions which can be 35 
done locally to the merchant without having to communicate 
are referred to as "Local Functions/Transactions." In order 
to provide support for many different types of Payment 
Instruments, the VPOS Payment Functionality have been 
categorized. 40 

Host payment functionality and transactions require com- 
munication with the host either immediately or at a later 
stage. Each of the host financial payment transactions come 
to this category and require a Payment Instrument. These 
transactions can be initiated with different types of Payment 45 
Instruments which the VPOS terminal supports. 

An authorization without capture transaction is used to 
validate the card holder's account number for a sale that 
needs to be performed at a later stage. The transaction does 
not confirm a sale's completion to the host, and there is no 50 
host data capture in this event. The VPOS captures this 
transaction record and later forwards it to the host to confirm 
the sale in a forced post transaction request. An authorization 
without capture transaction can be initiated both by the 
consumer and the merchant. 55 

A forced post transaction confirm to a host computer that 
a completion of a sale has been accomplished and requests 
data capture of the transaction. The forced post transaction 
is used as a follow-up transaction after doing an authoriza- 
tion (Online or Off-line) transaction. The transaction can be 60 
initiated only by the merchant. 

The authorization with post transaction is a combination 
of authorization without capture and forced post transac- 
tions. This transaction can be initiated both by the consumer 
and the merchant. 65 

The Offline post transaction is identical to the "authori- 
zation without capture" transaction, except that the transac- 
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tion is locally captured by the VPOS without initiating 
communication with a host. A forced post operation is done 
as a follow-up operation of this transaction. This transaction 
can be initiated by both the consumer and the merchant. 

The return transaction is used to credit the return amount 
electronically to the consumer's account when a purchased 
merchandise is returned. The VPOS captures the return 
transaction record when the merchandise is returned, and 
this transaction can be initiated only by the merchant. 

The void transaction cancels a previously completed draft 
capture transaction. The VPOS GUI provides an interface 
for retrieving a transaction record required to be voided from 
the batch and passes it to the Authorization/Data-Capture 
module after confirmation. The batch record is updated to 
reflect the voided transaction after getting an approval from 
the gateway. This transaction can be initiated only by the 
merchant. 

The pre-authorization transaction is identical to the autho- 
rization without capture transaction, but the consumers' 
"open-to-buy" amount is reduced by the pre-authorization 
amount. An example of this type of transaction is the 
"check-in" transaction in a hotel environment. A check-in 
transaction sends a pre-authorization request to the host, so 
that an amount required for the customers' stay in the hotel 
is reserved. The pre-authorization transaction is followed by 
a pre-authorization complete transaction. This transaction 
can be initiated both by the consumer and the merchant. 

The pre-authorization complete transaction is done as a 
follow-up to the pre-authorization transaction This transac- 
tion informs the host of the actual transaction amount. The 
pre-authorization complete transaction amount could be 
more or less than the pre-authorization amount. An example 
is the "check-out" transaction in a hotel environment. The 
checkout amount can be less than or more than the check-in 
amount. This transaction can only be initiated by a merchant. 

The adjust transaction is initiated to make a correction to 
the amount of a previously completed transaction. The 
adjust transaction can be initiated only by the merchant. The 
host administrative transactions do not require any payment 
instrument. The balance inquiry transaction is used for 
on-line inquiry into the balance of the merchant's account. 
The batch data or the configuration data is not affected by 
this transaction. 

The reconciliation or close transaction is processed at the 
end of the day to start the settlement process for the 
transactions captured by the host for that particular VPOS. 

The host log-on transaction is an administrative transac- 
tion which is used to synchronize the VPOS with the host at 
the start of the day and also initiate a fresh batch at the VPOS 
terminal. 

The parameters download transaction is used to download 
the VPOS configuration information from the host and 
set-up the VPOS in the event of any change in the configu- 
ration data. A test transaction is used to detect the presence 
of a host and the status of a link from the VPOS to the host. 

Local transactions or functions are initiated by a merchant 
and do not require communication with the gateway. These 
transactions can only be initiated by a merchant. The totals 
or accumulators review is a local information inquiry func- 
tion and is used to retrieve the local (merchant's) totals. The 
detail transaction or the batch review function is used to 
retrieve all the records from the transaction log or the batch. 
The clear batch function is used to start a fresh batch. This 
transaction is utilized to electronically reconcile the VPOS 
with the host and to manually reconcile the VPOS with the 
host After completing the manual reconciliation processing, 
the merchant can initiate this transaction to start a fresh 
batch. 
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The clear accumulator function is similar to the clear 
batch functionality and resets all VPOS terminal accumula- 
tors to zero. This function is required when the merchant is 
not able to reconcile the VPOS with the host electronically. 

The VPOS unlock or start transaction is a local function 
used to start the VPOS at the start of the day. The VPOS lock 
or stop function is used to Lock or stop the VPOS from 
accepting any transactions. The VPOS configuration setup 
function is used to setup the VPOS configuration data. The 
VPOS configuration data is divided into different tables, for 
example, the Card/Issuer Definition Table (CDT), the Host/ 
acquirer Definition Table (HDT), the Communications 
Parameters Table (CPT) and the Terminal Configuration 
Table (TCI). The following sections explain each of these 
configuration tables in detail. 

Payment Instruments 

As discussed above, the VPOS terminal supports different 
Payment Instruments and each of the Payment Functions 
described above can be initiated by these different Payment 20 
Instruments. The consumer making a purchase from a mer- 
chant provides a choice of payment methods depending 
upon their personal preference. The Payment Instrument 
Class Hierarchy, which is used by the different VPOS 
terminal Payment Functions is described below. 

Message Sequence Diagram 

FIG. 17 shows a typical message flow between the 
consumer, merchant, VPOS terminal and the Gateway. This 
section describes the different classes fisted in the previous 
section, their data and members, and defines the type of the 
transaction that is to be performed. Processing commences 
at 1700 when a merchant server receives a sales order and 
passes it via the VPOS Graphical User Interface (GUI) 1710 
to an authorizer 1720 for approval and subsequent protocol 
processing 1730 and ultimately transmission via the gateway 
1740 to the network. 
Class Name: 

CVPCLTransaction 
Data: 

Transaction Type (int) 

Transaction Date and Time (CPCLDateTime) 
Card Definition Table (CVPCL_CDT) 
Host Definition Table (CVPCL_HDT) 
Communications Parameters Table (CVPCL__CPT) 
Terminal Configuration Parameters CVPCL_TCT) 
Batch Record (CVPCLBatch) 
Accumulator Record (CVPCLAccum) 
Member Functions: 
CVPCLTransaction( ); 
EStatus GetTransType( ); 
EStatus GetTransDateTime(CPCLDateTime&); 
EStatus SetTransType{const int); 
virtual EStatus InitializeTrans(TVPOSParamsBlk *>0; 
virtual EStatus ExecuteTrans(TVPOSResultsBlk *)-0; 
virtual EStatus ShutDown( )=0; 

Host Transaction Class Definitions 

This section contains all the host transaction class defi- 
nitions. 

Host Transaction Class (CVPCLHostTrans) 65 

This is an abstract base class derived from the CVP- 
CLTransaction class and is used for deriving transaction 



classes which need to communicate with the host either 
inmediately or at a later stage. 
Class Name: 

CVPCLHostTrans 
Data: 

Member Functions: 
CVPCLHostTrans( ); 



40 



45 
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Financial Transaction Class 
(CVPCLFinancialTrans) 

This is an abstract base class derived from the CVP- 
CLHostTrans. This class is used to derive transaction which 
a payment instrument (e.g., a Credit Card) associated with 
them to perform the transaction. 
Class Name: 

CVPCLFinancialTrans 
Data: 

Transaction Amount (CVPCLAmt) 
Purchase Order Number (chartf ]]) 
Transaction Number (char[ ]) 
Authorization Identification Number (char[ ]) 
Retrieval Reference Number (char[ ]) 
Batch (CVPCLBatch) 
Accumulators (CVPCLAccumulators) 
Member Functions: 
CVPCLFinancialTrans ); 
EStatus GetTransAmt(CVPCLAmt&); 
EStatus GetPurchOrderNum(char *); 
EStatus GetTransRefNum(char *); 
EStatus GetRetRe£Num(char *); 
EStatus GetAuthId(char *); 
EStatus GetCurrency1Vpe(EPCLCurrency *); 
EStatus SetPurchOrderNum(const char *); 
EStatus SetTransRefNum(const char *); 
EStatus SetRetRefNum(const char *); 
EStatus SetAuthId(const char *); 
EStatus SetCurrencyiype (const char *) 

Financial Credit Card Transaction Class 
(CVPCLFinCCTrans) 

This is the base abstract class for the financial host 
transaction which require a Credit Card payment instrument. 
This class is derived from the CVPCLFinancialTrans. 
Class Name: 

CVPCLFinCCTrans 
Data: 

Credit Card Payment Instrument (CPCLCreditCard) 

Member Functions: 
CVPCLFinCCTrans( ); 

Credit Card Authorization Only Transaction Class 
(CVPCL__CCAuthOnly) 

This is the class derived from the CVPCLFinCCTrans 
class and implements the Authorization Only Transaction. 
Class Name: 

CVPCL_CCAuthOnly 
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Data: 

Member Functions: 

CVPCL_CCAuthOnly( ); 

EStatus InitializeTrans(TVPOSParamsBlk *); 

EStatus ExecuteTransfTVPOSResuitsBlk *); 

EStatus ShutDownTrans( ); 

EStatus FormBatchRec( ); 

10 

Credit Card Authorization with Capture Transaction 
Class (CVPCL_CCAuthCapt) 

This is the class derived from the CVPCLFinCCTrans 
class and implements the Authorization with Data Capture 15 
Transaction. 
Class Name: 

CVPCL_CCAuthCapt 
Data: 

Member Functions: 20 
CVPCL_CCAuthCapt( ); 
EStaus InitializeTrans(TVPOSParamsBlk *); 
EStatus ExecuteTrans(TVPOSResultsBlk *); 
EStatus ShutDownTrans( ); 25 
EStatus FormBatchRec( ); 

Credit Card Return Transaction Class (CVPCL_ 
CCReturn) 

30 

This is the class derived from the CVPCLFinCCTrans 
class and implements the Return Transaction. 
Class Name: 

CVPCL_CCRetum 
Data: 35 
Member Functions: 

CVPCL_CCReturn( ); 

EStatus InitializeTrans(TVPOSParanisBlk *); 

EStatus ExecuteTrans(TVPOSResultsBlk *); 40 

EStatus ShutDownTrans( ); 

EStatus FormBatchRec( ); 

Credit Card Pre-Authorization Transaction Class 

(CVPCL_CCPreAuth) 45 

This is the class derived from the CVPCLFinCCTrans 
class and implements the Pre-Authorization Transaction. 
Class Name: 

CVPCL_CCPreAuth 50 
Data: 

CVPCL_CCPreAuth( ); 

EStatus ExecuteTrans(TVPOSParamsBlk *); 

EStatus ExecuteTrans(TVPOSResultsBlk *); 55 

EStatus ShutDownTrans( ); 

EStatus FormBatchRec( ); 
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Data: 

Member Functions: 
CVPCL_CCOfflineAuth( ); 
EStatus InitializeTrans(TVPOSParamsBlk *); 
EStatus ExecuteTransfTVPOSResuitsBlk *); 
EStatus ShutE>ownTrans( ); 
EStatus FormBatchRec( ); 

Credit Card Adjust Transaction Class (CVPCL_ 
CCAdjust) 

This is the class derived from the CVPCLFinCCTrans 
class and implements the Adjust Transaction. 
Class Name: 

CVPCL_CCAdust 
Data: 

Member Functions: 
CVPCL_CCAdjust( ); 

EStatus InitializeTrans(TVPOSParamsBU *); 
EStatus ExecuteTransfTVPOSResuitsBlk *); 
EStatus ShutDownTrans( ); 
EStatus FormBatchRecf ); 

Credit Card Void Transaction Class (CVPCL_ 
CCVoid) 

This is the class derived from the CVPCLFinCCTrans 
class and implements the Void Transaction. 
Class Name: 

CVPCL_CC\bid 
Data: 

Member Functions: 
CVPCL_CCVoid( ); 

EStatus InitializeTrans(TVPOSParamsBlk *); 
EStatus ExecuteTransfTVPOSResultsBLk *); 
EStatus ShutDownTrans( ); 
EStatus FormBatchRec( ); 

Credit Card Forced Post Transaction Class 
(CVPCL__CCForcedPost) 

This is the class derived from the CVPCLFinCCTrans 
class and implements the Forced Post Transaction. 
Class Name: 

CVPCL_CCForcedPost 
Data: 

Member Functions: 
CVPCL_CCForcedPost( ); 
EStatus InitializeTrans(TVPOSParamsBlk ♦); 
EStatus ExecuteTranstTVPOSResultsBLk *); 
EStatus ShutDownTrans( ); 
EStatus FormBatchRec( ); 



Credit Card Off-line Authorization Only 
Transaction Class (CVPCL_CCOfflineAuth) 

This is the class derived from the CVPCLFinCCTrans 
class and implements the Offline Authorization Class Trans- 
action. 
Class Name: 

CVPCL_CCOfflineAuth 



60 Pre-Authorization Complete Transaction Class 

(CVPCL_CCPreAuthComp) 

This is the class derived from the CVPCLFinCCTrans 
class and implements the Pre-Authorization Completion 
65 Transaction. 
Class Name: 
C VP CL_CCPre Au th Comp 
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Data: 

Member Functions: 

CVPCL_CCPreAutbCbmp( ); 

EStatus IoitializeTrans(TVPOSParamsBlk *); 5 
EStatus ExecuteTrans(TVPOSResultsBlk *); 
EStatus ShutDownTrans{ ); 
EStatus FormBatchRec( ); 

10 

Credit Card Balance Inquiry Class (CVPCL_ 
CCBalancelnq) 

This class is derived from the CVPCLFinCCTrans class 
and is used to perform the Merchant Balance Inquiry func- 
tion. 

Class Name: 

CVPCL__CCBalanceInq 
Data: 

20 

Member Functions: 

CVPCL_CCBalanceInq( ); 

EStatus InitializeTrans(TVPOSParamsBlk *); 

EStatus ExecuteTrans(TVPOSResultsBlk *); ^ 

EStatus ShutDownTrans( ); 

Administrative Host Transaction Class 
(CVPCLAdminHostTrans) 

This is an abstract base class derived from the CVP- 30 
CLHostTrans class and is used to derive the administrative 
host transaction classes. 
Class Name: 

CVPCLAdminHostTrans 
Data: 35 

Member Functions: 

CVPCLAdminHostTrans( ); 

int GetHostIndex( ); 40 
EStatus SetHostlndex (const int); 

Reconcile Transaction Class (CVPCLReconcile) 

This is the class derived from the CVPCLAdminHost- 
Trans class and implements the Reconcile or Close func- 45 
tionality. 
Class Name: 

CVPCLReconcile 



Member Functions: 
CVPCLReconcile( ); 
EStatus InitiahzeTransCTVPOSParamsBlk *); 
EStatus ExecuteTrans(TVPOSResultsBlk *); 
EStatus ShutDownTrans( ); 

Host Log-on Transaction Class 
(CVPCLHostLogon) 

This is the class derived from the CVPCLAdminHost- 60 
Trans class and implements the Host Log-on Transaction. 
Class Name: 

CVPCLHostLogon 
Data: 

65 

Member Functions: 
CVPCLHostLogon( ); 
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EStatus InitializeTransfTVPOSParamsBlk *); 
EStatus ExecuteTrans(TVPOSResultsBlk *); 
EStatus ShmDownTrans( ); 

Parameters Download Transaction Class 
(CVPCLParamsDwnld) 

This is the class derived from the CVPCLAdminHost- 
Trans class and implements the Parameters Download 
(VPOS configuration information from the host) function- 
ality. 

Class Name: 

CVPCLParamsDwnld 
Data: 

Member Functions: 

CVPCLParamsDwnld( ); 

EStatus InitializeTransfTVPOSParamsBlk *); 
EStatus ExecuteTrans(TVPOSResultsBlk *); 
EStatus ShutDownTrans( ); 

Test Transaction Class (CVPCLTestHost) 

This is the class derived from the CVPCLAdminHost- 
Trans class and implements the Test functionality which is 
used to test the host and the link. 
Class Name: 

CVPCLTestHost 
Data: 

Member Functions: 
CVPCLTestHost( ); 

EStatus InitiaUzeTrans(TVPOSParamsBlk *); 
EStatus ExecuteTrans(TVPOSResultsBlk *); 
EStatus ShutDownTrans( ); 

Local Transaction Class Definitions 
(CVPCLLocalTrans) 

This is the abstract base class for all the transactions that 
are performed locally to the VPOS. 
Class Name: 

CVPCLLocalTrans 
Data: 

Record Number (int) 
Host Index (int) 
Member Functions: 
CVPCLocalTrans( ); 

int GetRecNum( ); 

int GetHostIndex( ); 

EStatus SetRecNum(const int); 

EStatus SetHostIndex(const int); 

Virtual POS Lock/Stop Class (CVPCLVPOSLock) 

This class implements the VPOS Lock or the Stop Local 
functionality. Under the locked state the VPOS does not 
accept any transaction requests. The class is derived from 
the CVPCLLocalTrans base class. 
Class Name: 

CVPCLVPOSLocK 
Data: 

Member Functions: 
CVPCLVPOSLock( ); 

EStatus InitializeTransfTVPOSParamsBlk *); 
EStatus ExecuteTrans(TVPOSResultsBlk *); 
EStatus ShutDownTrans( ); 
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Virtual POS UnlockyStart Class 
(CVPCLVPOSUnlock) 

This class implements the VPOS UnLock or the Start 
Local functionality- The class is derived from the CVP- 
CLLocalTrans base class. 
Class Name: 

CVPCLVPOSUnLock 
Data: 

Member Functions: 

CVPCLVPOSUnlock( ); 
EStatus InitializeTrans(TVPOSParamBlk *); 
EStatus ExecuteTrans(TVPOSResultsBlk *); 
EStatus ShutDownTrans( ); 

Transaction Data Administration Class 
(CWCLTransDataAdmin) 

This is an abstract base class used to derive the classes 
which are required to review/manage the transaction data 
which includes the batch data and the accumulator data. The 
class is derived from the CVPCLLocalTrans base class. 
Class Name: 

CVPCLTransDataAdmiu 
Data: 

Member Functions: 

CVPCLTransDataAdmin( ); 

Batch Review Class (CVPCLBatchReview) 

This class is derived from the CVPCLTransDataAdmin 
base class and implements the batch review functionality 
Class Name: 

CVPCLBatchReview 
Data: 

Member Functions: 

CVPCLBatchReview( ); 
EStatus InitiaUzeTrans(TVPOSParamBlk *); 
EStatus ExecuteTrans(TVPOSResultsBlk *); 
EStatus ShutDownTrans( ); 

Clear Batch Class (CVPCLClearBatch) 

This class is derived from the CVPCLTransDataAdmin 
base class and implements the clear batch functionality, 
which is used to clear the batch in the event of doing a 
manual reconciliation between the VPOS and the acquirer. 

Q ass Name: 
CVPCLClearBatch 
Data: 

Member Functions: 
CVPCLClearBatch( ); 
EStatus InitializeTrans(TVPOSParamsBlk *); 
EStatus ExecuteTrans(TVPOSResultsBlk *); 
EStatus ShutDownTrans( ); 

Accumulators Review Class 
(CVPCLAccumReview) 

This class is derived from the CVPCLTransDataAdmin 
base class and implements the Accumulators Review func- 
tionality. 
Class Name: 

CVPCLAccumReview 
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Data: 

Member Functions: 

CVPCLAccumReview( ); 

EStatus InitializeTrans(TVPOSParamsBlk *); 
EStatus ExecuteTrans(TVPOSResultsBlk *); 
EStatus ShutDownTrans( ); 

Clear Accumulators Class (CVPCLClearAccum) 

This class is derived from the CVPCLTransDataAdmin 
base class and implements the Accumulators Clear function- 
ality. 

Class Name: 

CVPCLClearAccum 
Data: 

Member Functions: 
CVPCLClearAccum( ); 

EStatus InitializeTrans(TVPOSParamsBlk *); 
EStatus ExecuteTrans(TVPOSResultsBlk *); 
EStatus ShutDownTrans( ); 

VPOS Configuration Data Administration Class 
(CVPCLConfigDataAdmin) 

This is an abstract base class and is used to derive classes 
which implement the functionality for managing the VPOS 
configuration data. The class is derived from the CVPCLLo- 
calTrans base class. 
Class Name: 

CVPCLConfigDataAdmin 
Data: 

Member Functions: 

Acquirer Data or the Host Definition Table Review 

Class (CVPCL 13 HDTReview) 
This class is derived from the CVPCLConfigDataAdmin 
class and implements the Host Definition Table Review 
functionality. 
Class Name: 

CVPCL_HDTReview 
Data: 

Member Functions: 

CVPCL__HDTReview( ); 

EStatus InitializeTrans(TVPOSParamsBlk *); 

EStatus ExecuteTrans(TVPOSResultsBlk *); 

EStatus ShutDownTrans( ); 

Issuer Data or the Card Definition Table Review 
Q ass (CVPCL_CDTReview) 

This class is derived from the CVPCLConfigDataAdmin 
class and implements the Card Definition Table Review 
functionality. 
Class Name: 

CVPCL__CDTReview 
Data: 

Member Functions: 
CVPCL_CDTReview( ); 
EStatus InitializeTrans(TVPOSParamsBlk *); 

EStatus ExecuteTrans(TVPOSResultsBlk *); 

EStatus ShutDownTrans( ); 

Communication Parameters Table Review Class 
(CVPCL_CPTReview) 

This class is derived from the CVPCLConfigDataAdmin 
class and implements the Communications Parameters Table 
Review functionality. 
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Class Name: 

CVPCL_CPTReview 
Data: 

Member Functions: 

CVPCL_CPTReview( ); 
EStatus InitializeTrans(TVPOSParamsBlk *); 

EStatus ExecuteTransfTVPOSResultsBlk *); 

EStatus ShutDownTrans( ); 

Terminal Configuration Table Review Class 
(CVPCL_TCTReview) 

This class is derived from the CVPCLConfigDataAdmin 
class and implements the Terminal Configuration Table 
Review functionality. 
Class Name: 

CVPCL_TCTReview 
Data: 

Member Functions: 

CVPCL_TCTReview( ); 
EStatus InitializeTransfTVPOSparamsBlk *); 

EStatus ExecuteTrans (TVPOSResultsBlk *); 

EStatus ShutDownTrans( ); 

Acquirer Data or the Host Definition Table Update 
Class (CVPCL_HDTUpdate) 

This class is derived from the CVPCLConfigDataAdmin 
class and implements the Host Definition Table Update 
functionality. 
Class Name: 

CVPCL_HDTUpdate 
Data: 

Member Functions: 

CVPCL_HDTUpdate( ); 
EStatus InitializeTrans(TVPOSParamsBlk *); 
EStatus ExecuteTrans(TVPOSResultsBlk ♦); 
EStatus ShutDownTrans( ); 

Issuer Data or the Card Definition Table Update 
Class (CVPCL_CDTUpdate) 

This class is derived from the CVPCLConfigDataAdmin 
class and implements the Card Definition Table Update 
functionality. 
Class Name: 

CVPCL„CDTUpdate 
Data: 

Member Functions: 

CVPCL_CDTUpdate( ); 
EStatus InitializeTrans(TVPOSParamsBlk *); 
EStatus ExecuteTransfTVPOSResultsBlk *); 
EStatus ShutDownTrans( ); 

Communications Parameters Table Update Class 
(CVPCL_CPTUpdate) 

This class is derived from the CVPCLConfigDataAdmin 
class and implements the Communications Parameters Table 
Update functionality. 
Class Name: 

CVPCL_CPTUpdate 



Data: 
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Member Functions: 

CVPCL_CPTUpdate( ); 

EStatus InitializeTrans(TVPOSParamsBlk *); 

EStatus ExecuteTrans(TVPOSResultsBlk 

EStatus ShutDownTrans( ); 

Terminal Configuration Table Update Class 
(CVPCL_TCTUpdate) 

This class is derived from the CVPCLConfigDataAdmin 
class and implements the Terminal Configuration Table 
Update functionality. 
Class Name: 

CVPCL_TCTUpdate 
Data: 

Member Functions: 

CVPCL_TCTUpdate( ); 

EStatus InitializeTrans(TVPOSParamBlk *); 

EStatus ExecuteTrans(TVPOSResultsBlk *); 

EStatus ShutDownTrans( ); 
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Batch Class (CVPCLBatch) 

This class defines the batch record and the operations 
which are performed on the batch. 
Class Name: 

CVPCLBatch 
Data: 



Batch Record Structure (TVPOSBatchRec) 
// Definition of the TVPOSBatchRec is as below, 
typedef struct_VPOSBatchRec 

char szTransAmt(J 

char szTransDatc[]; 

char szTransTime[]; 

char szRetrieval 
RefNum[]; 

char szAuthId[]; 

char szOrigAmtft 



// Trans. Ref. No. sent by 
the host 

// Approval Code sent by the host 
// Original amount for - 
Adjust 

char szPurchOrderNum[]; 

char szBatcbNumft 

EPCLXransType TransType; 

EPCLPmtlnst Pmtlnst; 

EPCLCurrency CurrencyType; 

EPCLDecimals NumDecDigits; 

unsigned int nTrans // Running Ref. Number 

RefNum; gen. by the 

// VPOS for every approved txn. 
unsigned long InSTAN; // Sys. Trace Number incr. by VPOS 

// for every trans, that is trans, to host 
TPmtlnstData PaylnstData; 
} TVPOSBatchRec; 
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CVPCLBatchO; 

EStatus SetTransType(const EPCLTransTypc); 
EStatus SetRetRefNum(const char *); 
EStatus SetAulhId(const char *); 
EStatus SetPurchOrdcrNum(coast char *); 
EStatus SetTransRefNum(coast long); 
EStatus SctTransAmt(const char •); 
65 EStatuS SetBatchNum (const char '); 
EStatuS SelSTAN (coast long); 
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-continued 



EStatus SetDateMMDDYYYY(const char *); 
EStatus SetTimeHHMMSS(const char *); 
EStatus SetPmtInst(const EPCLPmtlnst); 
EStatus SetCCAcdNum (const char *); 
EStatus SetCCExpDate(const char *); 
EStatus SetOrigAmt(const char •); 
EStatus GetBatchRecOTVPOSBatchRec *); 
EStatus InitBatchO; 

EStatus OpenBatch (const char % FILE *% const char *); 
EStatus CloscBatch(FILE *); 

EStatus AddBatchRec 0; // Adds a record to the batch 

EStatus GetBatchRec (const long); // Gets a record from the batch 
EStatus Update Batch Rec (const long); // Update batch record with NR 
EStatus Delete BatchRec (const long); // Deletes the batch record 



Accumulator Class (CVPCLAccum) 

This class defines the Accumulator record and the opera- 
tions on the accumulators. 
Class Name: 

CVPCLAccum 
Data: 

Credit Amount (char szCreditAmt[AMT_SZ4-l]) 
Credit Count (int nCreditCnt) 
Debit Amount (char szDebitAmt[AMT_SZ+l) 
Debit Count (int nDebitCnt) 
Member Functions: 

inl OpenAccum(int EHandle); 

int GetAccum (int nAccumType, inl *pnAccumCnt, char 

*pszAccumAmt); 
int CloseAccum(int fHandle); 
int CleanAccum( ); 

Host Definition Table Class (CVPCL_HDT) 

This class defines the Host Definition Table record and the 
operation on the table. 
Class Name: 

CVPCL_HDT 
Data: 

Host Definition Table Record Structure 

(TVPOSHDTRec) 
The TVPOSHDTRec structure contains the following 

fields, 

typedef struct_VPOSHDTRec 



char szTennldf]; 

char szMerchldf]; 

char szBatchNum[J; 

char szTPDUft 

char szMI[]; 

char szHostNameQ 

EPCLHOstProtType HostProtType; 

EPCLHostProtSubType HostProtSubType; 

// Data Capture Required Flags 

VPOSBool EAuthOnlyDC; 

VPOSBool fAuthCaptDC; 

VPOSBool fForcedPostDc; 

VPOSBool fAdjustDC; 

VPOSBool fRetumDC, 

VPOSBool fOfflineAuthDC; 

VPOSBool fVbidDC; 

VPOSBool fPreAuthDC; 

VPOSBool fPreAuthCompDC; 
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unsigned int nNumAdv, // Max. No. of piggy-back 
trans, allowed 

unsigned int nTransRe£Num; 

unsigned long InSTAN; // Systems Trace Number 
} TVPOSHDTRec; 



Member Functions: 
10 CVPCL_HDT( ); 

EStatus Clean HDT( ); 
EStatus LoadHDTRec(const int); 
EStatus SaveHDTRec(const int); 
15 EStatus GetNumRecs(int *); 

EStatus GetHDTRec(TVPOSHDTRec *); 
EStatus GetTermId(char *); 
EStatus GetMerchId(char *); 
EStatus GetBatchNum(char *); 
EStatus GetTransRefNum(unsigned int *); 
EStatus GetTPDU(char *); 
EStatus GetNII(char *); 
EStatus GetHostName(char *); 
25 EStatus GetHostProt^pe(EPCLHostProtiype *); 

EStatus GetHostProtSubType(EPCLHostProtSubType *); 
EStatus GetNumAdv(unsigned int *); 
EStatus GetSTAN(unsigned long *); 
30 EStatus GetAuthOnlyDC(VPOSBool *); 
EStatus GetAuthCaptDC(VPOSBool *); 
EStatus GetAdjustDC(VPOSBool *); 
EStatus GetReturnDC(VPOSBool *); 
EStatus GetForcedPostDC(VPOSBool *); 
EStatus GetOflaineAuthDC(VPOSBool *); 
EStatus GetVoidDC(VPOSBool *); 
EStatus GetPreAuthDC(VPOSBool *); 
EStatus GetPreAuthCompDC(VPOSBool *); 
40 EStatus SetHDTRec(TVPOSHDTRec *); 
EStatus SetTermId(const char *); 
EStatus SetMerchId(const char *); 
EStatus SetBatchNum(const char *); 
45 EStatus SetTransRefNum(const unsigned int); 
EStatus SetTPDU(const char *); 
EStatus STAN(const unsigned long); 
EStatus SetNII(const char *); 
EStatus SetHostName(const char *); 
50 EStatus SetHostProtType(const EPCLHostProtType); 
EStatus Set HostProtSubType (const 

EPCLHostProtSubType); 
EStatus SetNumAdv(const int); 
EStatus SetAuthOnlyDC(const VPOSBool); 
EStatus SetAuthCaptDC(const VPOSBool); 
EStatus SetAdjustDC(const VPOSBool); 
EStatus SetRetumDC(const VPOSBool); 
EStatus SetForcedPostDC(const VPOSBool); 
60 EStatus SetOnTincAulhDC(const VPOSBool); 
EStatus SetVoidDC(const VPOSBool); 
EStatus SetPreAuthDC(const VPOSBool); 
EStatus SetPreAulhCompDC(const VPOSBool); 

Card Definition Table Class (CVPCL_CDT) 
This class defines the Card Definition Table record and the 
operations on the table. 
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Class Name: 

CVPCL_CDT 
Data: 

Card Definition Table Record Structure 

(TVPOSCDTRec) 
The TVPOSCDTRec structure contains the following 

fields, typdef struct_VPOSCDTRec 



char szPANLcfl; 
char szPANHitt 
char szCardLabelQ 
int tiHostlndcx; 
int aMinPANDigit; 
int mMaxPANDigit; 
// Transaction Allowed Flags 
VPOSBool fAuthOnlyAllwd; 
VPOSBool fAuthCaptAllwd; 
VPOSBool fForcedPosLAllwd; 
VPOSBool fAdjustAllwd; 
VPOSBool fReturnAllwd; 
VPOSBool fOSlineAuthAllwd; 
VPOSBool fVoidAllwd; 
VPOSBool fPreAuthAllwd; 
VPOSBool fPreAuthCompAllwd; 
} TVPOSCDTRec; 
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Member Functions: 
CVPCL_CDT( ); 
EStatus CleanCDT( ); 
EStatus LoadCDTRec(const int); 
EStatus SaveCDTRec(const int); 
EStatus GetNumRecs(int *); 
EStatus GetCDTRec(TVPOSCDTRec 1 
EStatus GetPANLo(char *); 
EStatus GetPANHi(char *); 
EStatus GetCardLabel(char *) 
EStatus GetCDTHostIndex(int *); 
EStatus GetMinPANDigit(int *); 
EStatus GetMaxPANDigit(int *); 
EStatus GetAuthOnlyAllwd(VPOSBool *); 
EStatus GetAuthCaptAUwd(VPOSBool *); 
EStatus GetAdjustAllwd(VPOSBool *); 
EStatus GetRetumAllwd(VPOSBool *); 
EStatus GetOfflineAuthAllwd(VPOSBool *); 
EStatus GetVoidAllwd(VPOSBool *); 
EStatus GetPreAuthAllwd(VPOSBool *); 
EStatus GetPreAuthCompAllwd(VPOSBool *); 
EStatus GetForcedPostAllwd(VPOSBool *); 
EStatus SetCDTRec( TVPOSCDTRec *); 
EStatus SetHostIndex(const int); 
EStatus SetMinPANDigit(const int); 
EStatus SetaxPANDigit(const int); 
EStatus SetPANLo(const char *); 
EStatus SetPANHi(const char *); 
EStatus SetCardLabel(const char *); 
EStatus SetAuthOnlyAllwd(const VPOSBool); 
EStatus SetAuthCaptAllwd(const VPOSBool); 
EStatus SetAdjustAllwd(const VPOSBool); 
EStatus SetReturnAllwd(const VPOSBool); 
EStatus SetForcedPostAllwd(const VPOSBool); 
EStatus SetOfflineAuthAUwd(const VPOSBool); 
EStatus SetVDidAllwd(const VPOSBool); 
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EStatus SetPreAuthAllwd(const VPOSBool); 
EStatus SetPreAuthCompAllwd(const VPOSBool); 

Communications Parameters Table Class (CVPCL_ 
CPT) 

This class defines the communications parameters table 
and the operations on the table. 
Class Name: 

CVPCL_CPT 
Data: 

Communications Parameters Table Record Structure 

(TVPOSCPTRec) 
The TVPOSCPTRec structure contains the following 

fields, 

typedef struct_VPOSCPTRec 



{ 

char 
char 
char 
int 

} TVPOSCPTRec; 
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szAcq PriAdd rcss[]; 
szAcqSecAddres s[ J 
szAcqTeiAddressf]; 
nRcspTlmcOut; 



Member Functions: 
CVPCL_CPT( ); 
EStatus CleanCPT( ); 
EStatus LoadCPTRec(const int); 
EStatus SaveCPTRec(const int); 
EStatus GetNumRecs(int *); 
EStatus GetCPTRec(TVPOSCPTRec *); 
EStatus GetAcqPriAddress(char *); 
EStatus GetAcqSecAddress(char *); 
EStatus GetAcqTerAddress(char *); 
EStatus GetRespTimeOut(int *); 
EStatus SetCPTRec(TVPOSCPTRec *); 
EStatus SetAcqPriAddress(const char *); 
EStatus SetAcqSecAddress(const char *); 
EStatus SetAcqTerAddress(const char *); 
EStatus SetRespTimeOut(const int); 

Terminal Configuration Table Class (CVPCL_ 
TCT) 

This class defines the VPOS terminal configuration 
parameters table and the operations on the table. 
Class Name: 

CVPCL__TCT 
Data: 

Terminal Configuration Table Record Structure 

(TVPOSTCTRec) 
The TVPOSTCTRec structure contains the following 

fields, 

typedef struct_VPOSTCTRec 



60 { 



char szMcrchNamc[J 
VPOSBool fVPOSLoct; 
} TVPOSTCTRec; 



// VPOS Lock/Unlock Toggle Flag 



Member Functions: 
CVPCL_TCT( ); 
EStatus LoadTCTRec( ); 
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EStatus SaveTCTRec( ); 

EStatus CleaoTCT( ); 

EStatus GetTCTRec(TVPOSTCTRec *); 

EStatus GetMerchNanie(char *); 

EStatus GetVPOSLock(VPOSBool *); 

EStatus SetMerchName(const char *); 

EStatus SetVPOSLock(const VPOSBool); 
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Amount Class (CVPCLAraount) 

This class defines the amount data items and the opera- 
tions on them. 
Class Name: 

CVPCLAmount 15 
Data: 

Amount (char[ ]) 

Currency Type (EPCLCurrency) 
Member Functions: 

20 

CVPCLAmount( ); 

EStatus Initialize(const CPCLAmount&); 
EStatus Initialize(const char *); 
EStatus Initialize(const long); 

25 

void operator«(const char +); 
void opera to r=(const long); 
EStatus GetAmount(char *); 
operator const char * ( )const; 

operator const long ( ); 30 
Payment Instruments Class (CPCLPmtlnst) 

This section defines the Payment Instrument Class hier- 
archy. FIG. 16 illustrates a transaction class hierarchy in 35 
accordance with a preferred embodiment. 
Class Name: 

CPCLPmtlnst 
Data: 

Payment Instrument Type (EPCLPmntlnst) 
Member Functions: 
CPCLPmtInst( ); 

EStatus GetPmtInstType(EPCLPmtInst *); 

Bank Cards Class (CPCLBankCard) 

This class is derived from the CPCLPmtlnst class and 
implements the bank cards class. 
Class Name: 

CPCLBankCard 
Data: 

Account Number (char[ ]) 
Expiration Date (CPCLDateUme) 
Index into the CDT table (int) 
Member Functions: 
CPCLBankCard( ); 

EStatus Initialize( ); 
EStatus SetAcctNum(const char *); 
EStatus SetExpDate(const char *); 
EStatus GetAcctNum(char *); 
EStatus GetExpDate(char *); 
EStatus ValidateCard( ); 
int GetCDTIndex( ); 
VPOSBool DoLuhnCheck( ); 
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VPOSBool DoCardRanging( ); 
EStatus DoValidateExpDate( ); 

Credit Cards Class (CPCLCreditCard) 

This class is derived from the CPCLBankCad class and 
has the same data and the methods as the CPCLBankCard 
class. 

Class Name: 

CPCLCreditCard 
Data: 

Member Functions: 
CPCLCreditCard( ); 

Debit Cards Class (CPCLDebitCard) 

This class is derived from the CVPCLBankCard class and 
implements the debit card class. 
Class Name: 

CPCLDebitCard 
Data: 

Card Holder Encrypted PIN (char[ ]) 
Member Functions: 
CPCLDebitCard( ); 
EStatus GetEncryptedPIN(char *); 
EStatus SetEncryptedPlN(char *); 

VPOS Class library Interface and API Definitions 

This section explains the classes which provide the inter- 
face to the VPOS class library. 

Data Structures Required for the VPOS Interface 
Class 

Transaction Parameters Structure (TVPOSParamsBlk)— 
This structure is a subset of all the transaction parameters 
required for the different transactions. 



40 



typedef struct_VPOSParamsBlk 



{ 



char szTransAmt[]; 



45 
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chai szPurchOrderNum[]; 

char szRctRcfNum[j 
chai szBatchNuml]; 

char szNewBatchNum[]; 

char szOrigAmtfJ; 

char szCPSDataj j 

char szAuth!d[]; 



// Without decimal point. 
// Left most two digits implied to 
be decimal digits 



// Auth Id for offline auth-only 
transaction 



int Hostlndex; 

unsigned int nTransRefNum; 
VPOSBool fVPOSLock; 
ECPSDataTypc eCPSType; 
EPCLTransType TransType; 
EStatus Trans Result; 
EPCLPmtlnst Pmtlnst; 
EPCLCuiTency CurrencyType; 
EPCIX>ecimals NumDccDigits; 
EVPCLAccumType Accurr.Typc; 
TPmtlnstData PaylnstData; 
u nion_ VPOSConfigData 

{ 

TVPOSHDTRec srHDTRec. 
TVPOSCDTRec srCDTRec; 
TVPOSCPTRcc srCPTRec; 
TVPOSTCTRec srTCTRec; 
} VPOSConfigData; 
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compliance while providing support for additional message 

-continued tnal m not enabled in SET - Th e architecture includes 
i^— ^ _ ^— — ^— isolation of cryptographic details in a single module to 

void "Context; // Context from the calling interface facilitate singe version government approval while maxi- 

ESutus (*vposCaiiBack)crvposResultsBlk *, void $ mizing the flexibility Q f me system for customization and 

} TvTOSParamsBik; facilitating transfer of updated versions on an acquirer 

specific basis. FIG. 18 is a block diagram of the extended 

Transaction Results Structure (TVPOSResultsBlk) — This SET architecture in accordance with a preferred embodi- 

structure contains all the fields returned from the host and ment. Processing commences at function block 2800 for a 

other fields which are required for doing terminal data 10 consumer-originated transaction via the World Wide Web 

capture, (WWW) or 1810 for a merchantoriginated transaction on 

the Internet. In either case control passes immediately to the 
WWW server 1820 for the transaction to be appropriately 

^— — — ^— — — ^— formatted and the appropriate interface page presented, 

typedef struct. vposResuitsBik ^ whether thc traasac tj 0 n is a store front 1822, shopping cart 

charszNewBatchNumQ 1824, pay page 1826, standard terminal administration 

int nHostindex; 1828-1830 transaction, or an extended terminal transaction 

EStatus TYansRcsuit; 1834. If processing requires authentication of the 

TVPOSBatchRec srBatchRec; transaction, then control passes through the Virtual Point of 

TVPOSAccumRec srAccumRcc; „ , ' .. . r ~ . f , r , K nn 

charszCardLabeitl; 20 Sale (VPOS) Application Programming Interface (API) 

TVPOSHDTRec biHDTRcc; library 1840 for SET compliant transactions and through the 

tvtoscdtrcc srCDTRcc; VPOS API extensions library for extensions to the SET 

TVFO S^ eC Sr ^S CC; protocol. Then, at function block 1842, if the transaction is 

} twosr^i^uV^ CC 5r ^^ c ' SET compliant, and function block 1864 if the transaction is 

. 25 not SET compliant, a library of protocol stack information is 

used to conform the message before it is transmitted to a 

The various status codes for the enumeration EStatus are Gateway site for ultimate delivery to a bank host 1874 for 

detailed below. authorization. 

VPOS Interface Class (CVP OS Interface) Extended SET messages are processed at the Gateway site 

This class provides the interface to the VPOS Transaction 30 on a two track basis with the division criteria being SET 

ri r n, compliance (which will change over tune as more function - 

Uass ^ Drar > ality is put mto SET j or SET extensions. Set compliant 

rvpnS C * f messages are processed via the protocol stack library 1862, 

CVPOSIntertace whi]e §ET extensions are pr0C essed via the protocol stack 

Data: 35 extension bbrary 1864. Then, at function block 1870 the 

Member Functions: gateway engine processes SET and Host specific code 

CVPOSInterface( ); including gateway administration extensions 1872 that 

// Creates the Transaction Object, takes care bypass the normal processing and flow directly from the 

// of other initiation and executes the transaction. merchant and consumer server 1820 to the gateway admin- 

CVPCLTransaction *pclTransFactory(TVPOSParamsBlk 40 istration extensions 1872 to the Gateway Engine 1870. 

*); As described above, there are three channels by which 

EStatus DestroyTrans(CVPCLTransaction *); messages are exchanged between VPOS 1846 and GATE- 

VPOS API Definition WAY 1856 * 

™. - • L i_ a 1. Standard SET Messages 

This section explains in the VPOS API which are required 45 ^ sUmdard SET message s are originated by the mer- 

for interfacing with the VPOS Class Library. All the different software either via a pay page 1826 directly controlled 

VPOS transactions can be initiated using the API defined in by ^ or via an oper ator interface consisting of 

this section. a set of HTML pages and associated execu tables launched 

VPOS Terminal Architecture by the pages (e.g. pay page 1826 and standard terminal 

FIG. 25 is a block diagram of the VPOS Terminal 50 administration 1828-1830.) 

Architecture in accordance with a preferred embodiment. Each SET message type e.g. authorization v. capture 

The Internet 2500 provides the communication processing tnmsmits a different set of daU and each requires a different 

necessary to enabk the VPOS Terminal architecture. The Protocol Data Unit (PDU) to describe its encoding, 

terminal interface CGI 2520 communicates via the Internet Examples of how Standard SET messages are encoded are 

to provide information to the VPOS OLE Server 2550 which 55 given in the SET documentation previously incorporated by 

formats information in accordance with the VPOS API DLL reference 

2560 which uses the protocol class DLL2570 to flesh out the 2. Extended SET Messages 

message for delivery to the Gateway Server 2580. The The Extended SET messages are utilized as an escape 

collection of the VPOS OLE Server 2550, VPOS API DLL mechanism" to implement acquirer-specific messages such 

2560 and the Protocol Class DLL 2570 make up the VPOS 60 as settlement/reconciliation, employee logon/logoff, and 

Software Development ToolKit (SDK) which are used to Parameter download. The messages are developed as a set of 

enable VPOS applications for interfacing with an Operator name-value pairs encapsulated in a PKCS-7 wrap^rand 

- 54 q wrapped m Multipurpose Internet Mail Extensions (MIME), 

described in a book by N. Borenstein & N. Freed, "RFC 

VPOS/GATEWAY Architecture 65 lS2 \\ MIME (Multipurpose Internet Mail Extensions) Part 

The architecture of the Virtual Point of Sale (VPOS) and One: Mechanisms for Specifying and Describing the Format 

Virtual Gateway (GATEWAY) architecture maintains SET of Internet Message Bodies" (September 1993). The name- 
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value pairs can have arbitrary (8-bit) data, so arbitrary items 
can be passed through the extended SET channel, including 
executable programs and Dynamic Load Libraries (DLL)s, 

FIG. 18B illustrates a multipart MIME message with one 
Extended SET message and one Standard SET authorizing 5 
message. Mime is utilized as an outer wrapper 1890 to allow 
an Extended SET message 1891 to be transmitted as a 
component of messages embedded in one MIME multipart 
message. In this manner, a standard SET message can be 
sent with an Extended SET message in one VPOS/ 10 
GATEWAY communication transaction. 

Embedding the Extended SET messages in a PKCS-7 
wrapper enables the same message authentication to occur 
as in standard SET messages. Thus, for SET-compliant and 
non-SET-compliant messages, the same mechanism may be 15 
used to restrict which entities the VPOS or Gateway will 
trust in any communications. An important concept in 
Extended SET is that all messages, of any type, are sent in 
a uniform name/value pair format, thus allowing a single 
Protocol Data Unit to suffice for any type of message sent 20 
through the Extended SET channel. Since arbitrary data may 
be sent this way, a mechanism must be provided to preclude 
the use of the Extended SET channel by parties other than 
approved financial institutions. If this is not ensured, then 
the KSA and the U.S. Department of Commerce will not 25 
approve the software for export. 

SET itself to some degree ensures that this Extended SET 
channel is used only by financial institutions. The protocol 
stack extension library only processes messages that have 
been signed by a financial institution SET certificate that is 30 
in turn signed by a payment instrument brand certificate 
(such as Visa or MasterCard). Stronger control over the 
Extended SET channel can be achieved by further restricting 
processing of messages to those signed (either instead of or 
in addition to the financial institution SET certificate) by a 35 
second certificate belonging to a third-party agency, either 
governmental or private (e.g., VeriFone, as manufacturer of 
the software). 

In this way, a particular set of Extended SET messages 
can be implemented by Bank X, and a different set of 40 
messages by Bank Y. If a VPOS has an extended terminal 
transaction interface, as shown in FIG. 18A at block 1834 for 
Bank X, and has been configured to only accept messages 
from a Gateway with Bank X's certificate, then it will be 
able to communicate those messages to a Gateway that has 45 
the certificate for Bank X, and accepts messages of the types 
in Bank X's message set. The VPOS will not be able to 
connect to the Bank Y gateway, or to any other system that 
purports to communicate via Extended SET This restriction 
is further secured by utilizing a public key certificate that is 50 
"hard wired" into VPOS, and which is distributed only to 
gateways that use the Extended SET mechanism. 

FIG. 18C is an example flowchart of message processing 
in accordance with a preferred embodiment. Processing 
commences at function block 1880 when a message is 55 
received by an HTTPS server or other listener and passed to 
decision block 1883 to determine if the sending VPOS has 
transmitted an authentic message and if the VPOS is autho- 
rized to communicate with this gateway. If the message is 
not authentic, then the message is logged as an error and the 60 
error is handled as shown in function block 1889. If the 
message is authentic, then the message is decrypted at 
function block 1884 and the PDU parses the message into 
name/value pairs. Then, based on the message type and the 
extended SET version information, the remaining message 65 
is parsed at function block 1885 and the message is checked 
for conformance to the appropriate specification as shown at 
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decision block 1887. If the message does not conform, then 
it is logged and the error handled at function block 1889. If 
the message conforms to the proper specification in decision 
block 1887 then the message is translated into the appro- 
priate host format and sent to the host as shown in function 
block 1888. Thus, when a gateway receives an incoming 
message from a VPOS and parses the Extended SET portion 
of the message, a single MIME message can transmit a SET 
message and/or an Extended Set Message. 

An export license for the encryption can be obtained on a 
case-by-case basis, and since there will be potentially mil- 
lions of VPOS's, it is desirable to obtain a commodities 
jurisdiction for the VPOS, to enable a single version of the 
VPOS (rather than one version for each bank) to be sup- 
ported by the VPOS architecture. The architecture described 
here ensures that the single version of VPOS, no matter how 
it is configured with extended terminal transaction 
interfaces, cannot be used to communicate any data other 
than that contained in the extended SET messages that have 
been approved for export by the U.S. government to be used 
exclusively for a specific bank. 

FIG. 18D is an example of a simple message between 
VPOS and Gateway using the Extended SET channel 
enabling an employee to sign on, or "logon" to a given 
terminal in accordance with the subject invention. The 
message must contain the employee's logon ID, a password 
to be verified by the bank host computer, and the date and 
time as shown at 1894. 

While the contents of the message are shown without 
encryption in FIG. 18D, it should be noted that the infor- 
mation (including the logon password) are SET encrypted 
inside the PKCS-7 wrapper 1894. Certain fields may be 
designated as mandatory for an Extended SET message, to 
allow the Gateway or VPOS to decide how to handle the 
message. For the sake of clarity, in this message 1894, only 
two fields, "messagetype" and "ESETversion", are manda- 
tory. These fields inform the Gateway that this message is of 
type "logon," and that the VPOS is using version "1.0A" of 
the ESET message formats defined for the Gateway. In this 
embodiment, the length indicator "[5]" is used to distinguish 
the length (in bytes) of the field of type "messagetype" in the 
message. In this way, there are no special end-of-data 
characters, and therefore arbitrary data need not have any 
"escaped" characters. 

It should be noted that using escaped characters will work 
equally well. Total message integrity is assured by the digital 
signatures in the PKCS-7 wrapper. This does not, however, 
preclude the use of other checksumming schemes for addi- 
tional pinpointing of transmission or encoding errors. The 
messagetype and ESETversion name/value pairs facilitate 
Gateway look up of what name/value pairs are expected in 
the "logon" message. Some name/value pairs may be 
mandatory, and others may be optional. 

FIG. 18E is an example of a simple message between 
VPOS and Gateway using the Extended SET channel 
enabling an employee to sign on, or "logon" to a given 
terminal accordance with the subject invention. In response 
to the logon request message from a VPOS, the Gateway 
may respond with a "logon accepted" message 1894, as 
depicted in FIG. 18E, which VPOS, upon receipt and 
authentication, then uses to unlock the terminal for that user. 

FIG. 49 shows the VPOS authenticates an incoming 
response to a request in accordance with a preferred embodi- 
ment. Processing commences at function block 4930 when 
a message is received by the HTTPS, SET server, or other 
listener that originated the request to which this response 
corresponds. The message is passed to decision block 4940 
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to determine if the sending Gateway has transmitted an 
authentic message and if the gateway is authorized to 
communicate with this VPOS. If the message is not 
authentic, then the message is logged as an error or possible 
attack and the error is handled as shown in function block 5 
4970. If the message is authentic, then the message is 
decrypted at function block 4950 and the PDU parses the 
message into name/value pairs. Then, based on the message 
type and the extended SET version information, the remain- 
ing message is parsed at function block 4960 and the 10 
message is checked for conformance to the appropriate 
specification as shown at decision block 4980. If the mes- 
sage does not conform, then it is logged and the error 
handled at function block 4970. If the message conforms to 
the proper specification in decision block 4980 then the 15 
message is translated into a standardized argument string to 
be passed to the appropriate executable or code entry point 
in the VPOS, as shown in function block 4990. Thus, when 
a VPOS receives an incoming message from a Gateway and 
parses the Extended SET portion of the message, the mes- 20 
sage may cause VPOS to execute a program that takes action 
or queries the user to take action. 
3. Gateway-initiated Messages 

Since all SET messages between a merchant and an 
acquirer are currently merchant-initiated (as specified in the 25 
SET documentation), there must be a separate mechanism 
for initiating a message from a gateway, for example to 
request the upload of management information base (MIB) 
data, or to download new parameters. This is accomplished 
by requiring the gateway to send a message to the merchant 30 
via a MIME-encapsulated PKCS-7 conformant message 
containing name-value pairs to the merchant server directly, 
rather than to the SET module. This channel is shown in 
FIG. 18Aat block 1860. 



standard model of distribution of software that is customized 
for small target market segments. 

The more interesting case, and the one that concerns the 
novel use of the Extended SET channel, is where the 
potential merchant acquires, through some non-bank 
channel, a "generic" VPOS which has not yet been custom- 
ized to interact with a specific bank. This VPOS can com- 
municate with a "test gateway", which the merchant may use 
to experiment with the various features of VPOS and to test 
the integration of the VPOS into a total online storefront. 

In order to actually transact business over the Internet, the 
merchant must first obtain a merchant ID from the merchant 
bank with which he signs an acquiring agreement. For online 
payment processing, the merchant must also obtain an 
appropriate set of digital credentials in the form of public 
key certificates and possibly additional passwords, depend- 
ing on the financial institution. Once these credentials are 
obtained, the merchant is ready to customize the already- 
obtained VPOS to communicate with a merchant bank's 
gateway. 

Using the built-in "serial number" certificate and the Test 
Gateway public key certificate (which is "hard-wired" into 
the VPOS software), it is possible to securely download a 
particular bank's customization application to a specific 
copy of the VPOS software. Once the VPOS is appropriately 
configured, the last stage of customization download is to 
configure the VPOS so that it only responds to a public key 
certificate of the merchant's acquirer. This process is illus- 
trated here in the context of a merchant who obtains a VPOS 
that talks to the VeriFone test gateway, and desires to 
customize the VPOS to interact with a gateway at a bank. 

The merchant has purchased a VPOS from a non-bank 
channel. The version communicates with the VeriFone Test 
Gateway. The merchant uses the gateway to learn about 



G. 18Aat block 1860. , e us j ne VPOS, and to test the integration of his storefront 

The message is verified for origination from the acquirer, 35 » ^ ^ m system ^ merchaQt also obtains 



system with his payment system. The merchant also obtains 
certificates for payment processing from a bank, the mer- 
chant bank of choice for the merchant. The merchant is now 
ready to customize VPOS to talk to the bank gateway. The 
flowchart for the merchant interaction with the Test Gateway 
is shown in FIG. 50. 

The merchant begins at function block 5000, where the 
newly-obtained merchant SET certificates are installed in 
the VPOS. The merchant then directs the VPOS to connect 
45 to the VeriFone Test Gateway, by selecting this option from 
the VPOS terminal administration home page 5005. The 
choice of this option invokes an extended terminal admin 
page from the default set of such pages supplied with the 
generic version of VPOS. This program guides the customi- 
50 zation process. 

The merchant, interacting with the extended terminal 
admin page, navigates to the list of gateways which is 
maintained by the Test Gateway, and selects the bank to 
connect by selecting from the list of banks, at function block 
55 5018. During this process, the merchant's public key cer- 
tificates are uploaded to the Test Gateway, and checked (at 
decision block 5025) to verify that the certificates have been 
signed by the bank to customize the bank for the VPOS. If 
the certificates do not match, the merchant is advised of the 
6 o situation in function block 5028, and must select a different 
bank. If the certificates are not valid SET certificates as 
detected at decision block 5020, the merchant is advised at 
function block 5028, and the session terminates. If the 

certificates are valid and match the selected bank, customi- 

lnvoive moa in canon or rcpiawuiem ui, vaouj^iv, » . . , . , 

front 1822, shopping cart 1824, pay page 1826, standard 65 zation continues at function block 8030. 
terminal administration transaction interface 1828-1830 or The extended terminal administration program in VPOS 
an extended terminal transaction interface 1834. This is a receives a list of the customization from the Test Gateway 



and is utilized to either initialize a merchant action, such as 
to update the merchant's administration page (for example 
by blinking a message saying "PLEASE RE-INITIALIZE 
YOUR TERMINAL"), or by initiating a request/response 
message pair originating from the merchant (for example, 40 
"HERE ARE THE CONTENTS OF MY MIB"). This is 
achieved by calling one of the extended terminal transaction 
interfaces (FIG. 18Aat 1834), which in turn initiates a SET 
or Extended SET transaction. 

Gateway Customization via the Extended Set 
Channel 

Gateway customization in extended SET is extremely 
powerful and a novel concept for VPOS processing. Each 
VPOS contains one or more "serial numbers" unique to each 
copy of the software (a serial number may be embedded in 
the software, or may be a component of a public key 
certificate used in the software). Once a merchant has 
selected an acquirer and obtained the appropriate 
certificates, the VPOS can be customized utilizing the com- 
munication link and messages containing customization 
applications. 

A bank distributes VPOS via different sales channels. The 
first is direct from a bank to an existing merchant with whom 
the bank already has an existing relationship. In this case, a 
version of VPOS already customized for a bank is sent to the 
merchant, either directly by a bank, or through a third-party 
distributor or service bureau. The customizations may 
involve modification or replacement of, for example, a store 
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that must be performed to specialize the VPOS for a specific another. In a preferred embodiment, a TID is represented as 

bank. Some of these customizations are mandatory, while a token in a pool that can be associated with a particular 

others are optional. In function block 5030, the VPOS transaction. 

advises the merchant of the customizations, prompting for Jo provide for this requirement, the VPOS provides a TID 

any choices that must be made by the merchant. The 5 pool in tabular form in a database management system 

merchant's actions at this point drive decision block 5035, (DBMS). This table has two columns: TID NAME & 

in which the VPOS either returns itself to the "generic" state Allocation date/time. If the TID date is null, then the TID is 

and terminates the interaction, or begins the configuration of no t in use and may be assigned. A date/time field is utilized 

the VPOS, depending on the merchant's confirmation of the to allow TID allocations to expire. TID requests are made 

request to begin the configuration. to utilizing a SQL query on the TID Pool to find the first null 

If the merchant has authorized the changes, control is or expired date/time, which is replaced with the current 
passed to function block 5040 where, the POS stores the date/time and the TID name returned, 
certificates of any gateways that it will allow future con- VPOS 
figuration changes to be initiated from in its database. This Remote VPU5 
may be only a specific bank, such as a bank and the Test 15 y^e unique architecture of the Cardholder 120, Merchant 
Gateway, or other combinations. If only a single, non-Test, m ^ Gateway 140, as shown in FIG. 13, provides 
bank-owned, gateway is allowed to download changes, the communication capability between the modules utilizing the 
VPOS is no longer customizable for any other bank. Then, internet to support linkages 150 and 170. Since the Internet 
a new copy would be purchased by the merchant to have it ^ ^ pervasive, and access is available from virtually any 
customized for another bank. If the Test Gateway is still 20 compu ter, utilizing the Internet as the communication back- 
allowed to customize the VPOS, the merchant could switch bonc for connecting the cardholder, merchant and access to 
to another merchant bank and have the current VPOS mc authorizing bank through a gateway allows the merchant 
updated to work with the new bank. VPOS software to be remotely located from the merchant's 

In function block 5050, the customizations are down- premises. For example, the cardholder could pay for goods 

loaded to the VPOS. The downloads comprise a set of 2 ' from any computer system attached to the Internet at any 

HTML pages and a set of executable programs or scripts that location in the world. Similarly, the merchant VPOS system 

read data from the merchant, perform various functions, and could be located at a central host site where merchant VPOS 

present data to the merchant. In general, the customizations systems for various merchants all resided on a single host 

downloaded may augment or replace in part or in whole any with their separate access points to the Internet. The mer- 

and all of function blocks 1822, 1824, 1826, 1828, 1830, or 30 chant could utilize any other computer attached to the 

1834 in FIG. 18A. At a minimum, the terminal "home page" Internet utilizing a SSL or SET protocol to query the remote 

will be replaced so that it points to the new functionality. At VPOS system and obtain capture information, payment 

this point, the customization of the VPOS has been administration information, inventory control information, 

completed, and the merchant may now begin sending pay- ^ audit information and process customer satisfaction infor- 

ment requests to the merchant bank or processor through the mation. Thus, without having to incur the overhead of 

VPOS. maintaining sufficient computer processing power to support 

the VPOS software, a merchant can obtain the information 

Thread Safe VPOS — TID Allocation necessary to run a business smoothly and avoid hiring IS 

Physical terminals process a single transaction at a time « P ersonnel t0 maintaiQ ^ W0S S y Stem ' 

since clerks are usually only able to process one transaction ypgg Merchant Processing 
at a time. Web Servers can process many transactions at a 

time, so payment requests can often occur simultaneously. Multiple merchant processing refers to the ability of a 

Thus, the VPOS Software must have support for multi- plurality of merchants to process their individual VPOS 

tasking and provide support for multiple threads to be active 45 transactions securely on a single computer. The architecture 

at the same time in the same system as well as the same relies on each payment page obtaining the merchant name in 

process. This requirement is relatively straight forward. a hidden field on the payment page. The VPOS engine 

However, the authorizing banks require that all transaction receives the merchant name with a particular transaction and 

requests include a Terminal ID (TID), and, for many banks, synchronizes the processing utilizing a Set Merchant 

no single TID may be active in any two transaction requests 50 method. This command causes the VPOS API to look up a 

that overlap in time. Thus, the VPOS requires dynamic unique registry tree based on the merchant name. This 

allocation of TIDs to requesting threads. process causes the VPOS engine to engage the appropriate 

One way of providing for multiple TID's is to assign a configuration to process the transaction at hand utilizing a 

"base" TID, and either an "extension" (a set of extra digits Registry Tree. A registry tree contains Card Definition 

appended to the base), or an increment (a number which is 55 Tables (CDT)s, acquirer Definition Tables (ADT)s, Mer- 

added to the base to obtain the complete TID). While such chant Definition Tables (MDT)s, Protocol Configuration 

a solution can be used for the majority of banks and Tables (PCT)s, etc. The CDTs point to specific ADTs since 

processors, not all banksftrocessors can accommodate this each supported card can be supplied by a distinct acquirer, 

solution. One example is First Data Corporation. For its This is one form of split connection. Each of the ADTs in 

ENVOY protocol, the terminal ID must use the Luhn check 60 turn point to PCTs, and some acquirers can support multiple 

as recited in an ISO remark, which adds a checksum digit to parallel gateways. A merchant's name refers to a unique 

the terminal ID to reduce chances of fraud or of mistyped database in the database management system which contains 

information. Thus, to be general enough to handle all for example, TIDs. 

bank/processor situations, a pool of TID's is used. The So, for example, to fully qualify a particular merchant in 

TID's stored in the pool need not be a sequential set of 65 a multi-merchant system, the acquirer Definition Table is 

numbers; in fact they can be alpha/special/numeric queried to ascertain the particular Gateway (VFlTest), then 

combinations, and the TID's need have no relation to one if Bank of America requires verification of network com- 
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munication information, the particular CardDT is accessed the index is incremented at function block 1920 and the loop 

with for example VISA. The particular merchant will service reiterated to process the next card at function block 1930. If 

VISA transactions utilizing a particular acquirer. The par- all the cards have been processed, then control is returned to 

ticular piece of merchandise will also be detailed in a data the merchant program for processing the transaction at 

base. Finally, the merchant Configurations will also be 5 terminal 1970. 

stored in the database to facilitate E-mail and name lookup. FIGS. 20A through 20H are block diagrams and flow- 
charts setting forth the detaOed logic of thread processing in 
VPOS Client accordance with a preferred embodiment. FIG. 20A illus- 
Hie interaction between the VPOS and a client com- trates a prior art approach to POS processing utilized in most 
mences when a pay page solicits parameters of a transaction. 10 grocery stores and department stores today. POS Terminal 
Then, the parameters are validated to be sure the payment 2001 accepts transactions provided to it one at a time by 
instnunent, for example, cardnumber is not null. THen, a customers 2000. For each taction, POS Terminal 2001 
transaction object is created, eg. AUTHONLY, and the builds a transaction request 2002 and transmit it to acquiring 
object is initialized and stuffed with parameters of the bank 2004 over communications link 2003. 
transaction, eg. ao.se tpan(accnum), and the object is 15 FIG. 20B is a data structure 2002 representing a POS 
executed. This execution invokes the VPOS engine. The transaction request in accordance with a preferred embodi- 
VPOS engine further validates the parameters based on the ment. The data structure 2002 includes a Tip field 2005, 
particular merchant's configuration. For example, some which identifies the physical terminal from which the trans- 
merchants do not accept American Express Cards, but will action originates. In addition to the TID field, the data 
take Visa, and all merchants check the expiration date of the 20 structure also includes other data 2006 necessary to process 
card. Assuming a valid and acceptable card has been a transaction. This data includes such fields as a transaction 
tendered, then a TID is assigned (expiring, existing TIDs) or type, a transaction amount, a currency type (such as U.S. 
block a new TID from the TID Pool. This generates a STAN, dollars), credit card account number, credit card expiration 
XID, RRPID unique tag and creates an initial record in the date, etc. 

transaction database which is flagged as before gateway 25 FIG. 20C illustrates a VPOS architecture with account 

processing in case the transaction crashes and must be requests being processed by a single acquiring bank. VPOS 

backed out. Then the protocol parameters are identified in 2007 processes a plurality of customers 2000 concurrently, 

the registry based on card type, and a particular acquirer Far each such customer 2000, VPOS 2007 builds a data 

identified. Then, a protocol object is created and executed to structure 2010, representing the transaction to be performed 

extract results from the protocol object and the before 30 for that customer. Each data structure 2010 contains a unique 

gateway "bit" is flipped to again flag the location of the "virtual terminal" ID. VPOS 2007 selects a virtual terminal 

transaction in the process as it is submitted to the Gateway. id using database 2008. For each data structure 2010, VPOS 

The results received back from the Gateway are placed 2007 initiates communication with acquiring bank 2004 

into a transaction object with is reported back to the pay 35 using communication link 2003. 

page and ultimately back to the pay page user. FIG. 20D is a data structure 2010 representing a VPOS 

transaction request in accordance with a preferred embodi- 

VPOS Merchant Pay Customization ment data structure 2010 includes a TID field 2012, 

A novel feature of the VPOS software provides payment which identifies a virtual terminal © associated with a 

page customization based on a merchants preferences. This 40 particular transaction. In addition to the TID field 2012, the 

feature automatically lists cards that are accepted by a data structure also mcludes other data 2006 necessary to 

particular merchant based on the active terminal configura- process a transaction. This data includes such fields as a 

tion. Each approved card for a particular merchant is linked transaction type, a transaction amount, a currency type (such 

tothedisplayviaanURLthatprovidesapointertothecredit as U.S. dollars), credit card account number, credit card 

card information supported by the merchant. Each card has 45 expiration date, etc. 

an entry in a data structure referred to as the Card Definition FIG. 20E illustrates a TID allocation database 2008 10 

Table (CDT) accordance with a preferred embodiment. Database 2008 

A preferred embodiment of the VPOS merchant pay includes a TID allocation table 2011 TID allocation table 

customization software in accordance with a preferred 2011 includes a plurality of rows, one for each TID used by 

embodiment is provided in FIG. 19 which illustrates the 50 each acquiring bank. One such row 2013 * ^ rat «I itj 

logic utilizing a flowchart, and a listing of the source code detail Row 2013 includes a g°°d/semce order (GSO) 

below. Processing commences at terminal 1900 and imme- identifier 2014, which identifies the order bemg transmitted; 

diately flows to function block 1910 where an index variable * TID field 2015, which identifies a terminal ID that may be 

is initialized for stepping through each of the accepted used with a particular acquiring bank; and lan acquiring bank 

payment instruments for the merchant's page. Then, at 55 field 2016 which identifies the acquinng bank for M the 

function block 1930, a URLkey is obtained associated with TID is valid. In addition, row 2013 may optionally include 

the current merchant pay page and index value. The URL other fields 2017 that may be used in conjunction with the 

key is a registry key name that points to a picture of a credit order processing. A null GSO value ind.cates that the 

card that the merchant has associated with the pay page and TID/acquirer combination is not currently in use. 

which the merchant accepts as payment. Al output block 60 FIGS. 20F though 20H are flowcharts of the detailed logic 

1940 the card image associated with the URL key is used to perform virtual terminal ID allocation. FIG. 20F 

obtained and displayed on the terminal. The CDT entry is illustrates the main line operation of virtual TID allocation, 

obtained at function block 1950 utUizing the URLkey. The In step 2020, execution begins. In step 2021, a skeletal 

CDT is utilized for storing information associated with each transaction request structure is prepared. In step 2022, the 

card. Then, at decision block 1960, a test is performed to 65 main line routine obtains a virtual TID for inclusion within 

determine if the last payment method card has been pro- the transaction request structure, as will be more fully 

cessed and displayed on the merchant display. If not, then disclosed with reference to FIG. 20G, below. In step 2023, 
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the routine verifies that a TID was obtained. If the TID was 
not obtained, for example, if more transactions are currently 
being processed than there are TIDs, then execution contin- 
ues to step 2024. In step 2024, the transaction request is put 
on a queue for future processing. In step 2025, the routine 
waits for a transaction process to end, which would free up 
a TID in use. At that point, control resumes from step 2022, 
and the routine again attempts to obtain a TID. 

If the TID was successfully obtained in step 2023, control 
proceeds to step 2026. In step 2026, the routine submits the 
transaction to the acquiring bank. In step 2027, the transac- 
tion is processed. In step 2028, the routine makes a database 
call to free up the TID that was used in the transaction. In 
step 2029, transaction processing ends. 

FIG. 20G depicts in detail the process of obtaining a TID 
from the database. Execution begins in step 2040. In step 
2041, the routine constructs a database call to reserve a TID 
for processing, for example, by constructing an SQL state- 
ment to retrieve a TID row from the database. In step 2042, 
the routine executes the database call that was constructed in 
step 2041. In step 2043, the routine constructs a second 
database call to extract the TID from the row that was 
reserved in step 2042. In step 2044, the database call 
constructed in step 2043 is executed to obtain the TID. In 
step 2045, a return code is checked to verify whether the TID 
was successfully obtained. If the TID was successfully 
obtained, control proceeds to step 2046, which returns to the 
calling program. If, however the TID was not obtained, 
control proceeds to step 2047. In step 2047, the routine 
checks to see whether an excessive number of retries have 
already been attempted. If there have been an excessive 
number of retries, control proceeds to step 2048, which exits 
with an error indication. If there has not been an excessive 
number of retries, control proceeds once again to step 2043 
to retry the extraction operation. 

FIG. 20H depicts the operation of releasing a TID that had 
been used in a prior transaction. Execution begins in step 
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2060. In step 2062, the routine constructs a database call to 
update the row for the selected HD so that the value for the 
good and service order is null, thereby indicating that the 
selected TID is not associated with any good or service 
order, and is therefore free for reuse. In step 2064, the 
routine executes the SQL statements constructed in step 
2062, thereby releasing the TID for use in future transac- 
tions. In step 2069, the routine returns to the calling pro- 
gram. 

A source code listing for the transaction request process- 
ing is provided below in accordance with a preferred 
embodiment. 
#include"rr,h w 
#ifndeL_NT 
#define_JSTT 
extern void_setenvp( ); 
#endif 

l/iIi!Ilt!llii!lilIiI!ill!liIillli!i!M 
// AcquireBillHtml 

// On Pay page, output form entries to acquire billing 
information 

iiiwiiifiiiiiifiimiiiiiiiiiiiiiiim 

EStatus AcquireBillHtml(CWSINT&clWSINT, int nTot, 
CProf& clProfile, EPCLCurrency ecurrency) { 
//Current time 

time_t tNow; //figure out current year for Credit card 

expiry 
struct tm *tmNow; 
char szYear[DB_YEAR_S2>l]; 
char szAmount[FORM ATTED_CURRENCY+ 1 ] ; 



35 



time(&tNow); 

tmNow=localtime(&tNow); 

strftime(&szYear[0],(size_t)DB_YEAR_SZ+l, 

tmNow); //needs extra 1 for null 
int nYear=atoi(szYear); 



<%Y" 



/*<TH>Payment Type</TH>\n<TI>xINPUT SIZE - 20 NAME-b_bstrument VALUE-V" \ 
« d Pro file. m_b_instrument « "\"></TD>"\ 
« "7 

clWSINT « "cCENTERxTABLE BORDER=0xCAPTION ALIGN = TOPxB>Bill 
Tb</B></CAPTION>\n"; 

ctWSINT « "<TR ALIGN- LEFTxTH> Account Number </THxTD COLSPAN - 5>< INPUT 
SIZE = 56 MAXLENGTH =" 

« ACCT_NUM_SZ « "NAME=b_card> </TD></rR>\n"; 
clWSINT c< " <TR ALIGN-LEFT><TH>Namc on Card</THxTDxINPUT SIZE- 20 
MAXLENGTH="« NAME__SZ 

« "NAME-b_name VALUE-V" « clProfile.m__b-_name 
« T'> </ro><TH>Expiration</HI><TD>Month <S ELECT NAME = 
b_expire__month><OPTION> 01\n <OPT10N> 02\n" « 

"<OPTION> 03\n <OPTION> 04\n<OPTION> 05\n<OPTION> 06\n<OPTION> 
07\n<OPTION> 08\n<OPTION> 09\n" « 

"<OniON> 10\n<OPTION> 31\n<OPTION> 12\n</SELECT> Year <SELECT 
NAME « b_expire_year>^PTION>" « nYear» 

* i <OPnON>" « nYear + 1 « "<OPTION>" « nYear + 2 « "<OPTION>" « nYear 
+ 3 « "<OPTION>" « nYear + 4 « 
"</SELECr><ATJ></rR>\n T? ; 
//<TH>Expires</rHxTD>Month <INPUT SIZE -3 NAME-b_expire_month> Year < INPUT 
SIZE=5 NAME»b_e3qjire_year></TD></TR>\n"; 

clWSINT « "<TR ALIGN-LEFTxTH> Address Line l</THxTD COLSPAN-SxINPUT 
SlZE-56 MAXLENGTH=" « ADDR_SZ 

« "NAME=b_addrl VALUE=Y*" « clProtile.m_b_addrl « M \"></TD><^TR>\n"; 
clWSINT « "<TR A LIGN=LEFT><T}I> Address Line 2</THxTD COLSPAN-SxINPUT 
SlZE-56 MAXLENGTH-"ADDR_SZ 

« "NAME=b_addr2 VALUED" « cIProfilc.m_b_addr2 « - \"> </TD></TR>\n"; 
clWSINT « "<TR ALIGN- LEFr><TH>City</rHxTD><INPUT MAXLENGTH-" « 
CrTY_SZ « "NAME=b_city VALUEM"" 

« dProfile.m_b_city « T> </TD>" « M <TH>State/Prcvince</TH><TD><INPUT 
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MAXLENGTH=~ « STATE_SZ 

« "NAME-b_statc VALUER' « clProfile.m_b_stfltc « T> </rD></rR>Vn rt ; 
clWSINT « "<TR ALIGN=LEFT><TH>Counlry</TH><TD><rNPUT MAXLENGTH^ « 
COUNTRY_SZ 

« "NAME-b_country VALUE=Y*" « clProfUc.m_b country 
</TDxTH>Zip/Postal Code</TH><TD><INPUT MAXLENGTH=" 

« ZIP_SZ « w NAME-b_zip VALUE-\""« cIProfUe.m_b_zip « "\"> 
</TD></TR>\n"; 

clWSINT « **<TR ALIGN=LEFT><TH>EmaU</TH><TD><INPUT MAXLENGTH="« 
DEMAIL_SZ « "NAME=b_email VALU&-V"' 

« clProule.m_b_email « *T> </TD>" « "<TH>Phone</TH><TD><lNPUT 
MAXLENGTH-" « BPHONE_NUM_SZ 

« " NAM E=b_p hone VALUE=\"" « clProfile.m_b_phoae « V> 
</TD></TR>Vq"; 

clWSINT « M </TABLE></CENTER>cP>\n"; 

//NPW« "NAME-b_addrl> <JTD>" « **<TH>Paymenl 
InstrumentVTH>\n<TD><SELECr NAME -b_instrument>"; 

//hack from ini (bug) which pay instruments supported 

//NPW clWSINT « "<OPTION>Credjt Card\n" « "<OPTTON>Debit 
Card\n</SELECT></rDx/TR>\n"; 

CurrFormalfnTot, eCurrency, szAmount); 

clWSINT « ** <CENTER><FONT SIZE-5>Total - " « szAmount « 
"</FONT></CENTER>"; 
return (eSuccess); 

} 

tmmimtimmtMMiniMiimiimiuimmtmmi 

fl PayButtonsHtml 

// Output buttons on pay page: return to shop, pay, pay window, 
// modify order 

munimiimttumiimttmuiimmimtimmnttmi 

void PayButtonsHtml (CWSINT& clWSINT, char" pszShopUrl, CRRReg& clReg) { 

char *pszHomeUrl - clWSINT. LookUp("bome_urP'); 

char "-pszModifyUrl - cIWSINT.LookUp("Modify_urr); 

char "pszSoftUrl - clWSINT. LookUp^soft^url"); 

if (IpszHomeUrl) pszHomeUrl ~ pszShopUrl; //Home Page 

//if (IpszModifyUrl) pszModifyUrl = pszShopUrl; //Shopping Cart typically 

clWSINT « "<CENTERxH4>By pressing the Pay! button I agree to pay the above total 
amount<br> according to the card issuer agreement <H4></CENTER>\d'*; 

clWSINT « "<CENTER>\n<A HREF « pszShopUrl « "> <IMG SRC-" « 
clReg.m_szReturnShop « "BORDER = 0></A>\n"; 
#ifdef_SC 

clWSINT « "<INPUTTYPE - IMAGE NAME - gso SRC - " « clReg.m_szModifyOrder « 
" BORDER = 0>\n"; 
#else 

if (pszModifyUrl) 

clWSINT « "<A HREF « " « pszModfiyUrl « "> <IMG SRC-" « 
cl Reg. rn„szMod if yOd rcr « "BORDER - (WA>\n"; 
#endif 

clWSINT « "<INPUTTYPE - HIDDEN NAME - home_url VALUE - " « pszHomeUrl « 

« "<INPUTTYPE «- IMAGE NAME = VPOS SRC ° " « clReg.m_szPay « "BORDER = 
0>\n" 

« "<INPUTTYPE - HIDDEN NAME = shop__url VALUE =" « pszShopUrl « ">\n" 
« "<INPUTTYPE - HIDDEN NAME - store VALUE -" clWSINT.LookUp("store") « 
">\n"; //Can't be NULL or error previously 
if (pszSoflUrl) 

clWSINT « "<L\ T PUT TYPE - HIDDEN NAME - soft_url VALUE « pszSoftUrl 

« ">\n"; 

clWSINT « " </CENTER>\n" ; 

} 

immiuuimmsmnmiwmiimmimmtmmimu 

// DisplayPayPage 

//Outputs billing form, buttons, and static gso 

mtmummnmttinmmmiimimmnmmmttm 

EStatus DisplayPayPage(CWSINT& clWSINT, CRRRegS clReg, int nError) { 
EStatus eStat; 

char szFileLine[BUFFER__SZ + 1]; 

char *pszTag, -pszRefererUrl, "pszShopUrl, •pszExePath, -pszServerName; 

time t tNow; 

int nTagExist » FALSE; 

HXEY hCardsKey; //To enumerate cards 

long rctCode; 

int nNoCards; 

DWORD dwtype, dwlen; 

HKEY hCardKey; 

char szCard Bu £f MAX_PATH + \\ szCardPic(MAX_PATH + 1]; 
#ifdef_SC 

CPOLBk cIBkGso; 
#else 
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char "pszTxn, *pszGsoNum, *pszGso Opaque, •pszTot; 
#endif 

//Shaping headers. If come from gso page and cookies are not set, set. 

CProf 'pProfUe; 

p Profile = new CProfO; 

if OpProfile) return (eRRNewFailed); 

eStat - pProfile->Intl(clWSINT); 

if (eStat !« eSuccess) return (eStat); /Jink failed 
#ifde£_SC /'No session coolie for the pay page. This means the user will either use a long 
term cookie or type in their info each time*/ 

clWSINT « "Set-Cookie: profile-" « pProfUe->GetCookieLine() « pathWVn"; 
/* if (clWSINT.LookUp("Server Name")) 

clWSINT « ";domaln =" « clWSINT.LookUp ("Server Name") « ^Vd";*/ 

#endif 
#ifdeL_SC 

//Shipping filled in? 

if (!{pProfile->m_s_name{0] && pProfile->m_s_addrl[0] && pProfile->m__s_city[0] && 
pProfile->m^s_state(0] && 

pProfile->m_s_zip[0] && pProfUe->m_6_country(0] && pPiofile->m„s_Khip[OD) { 
eStat = DisplayGsoPage(clWSINT, clRcg, ERROR_DISPLAY); //bug, return 

correct? 

return eStat; 

} 

//Creates shopping basket from CGI/Cookies 
eStat - clBkGso.Init(clWSINT, *pProfile, clReg); 
if (eStat != eSuccess) return (eStat); //eRRBasketCreateError 
//Cookies then other headers 
clBkGso.ToCookies(clW$lNT, REGULAR); 
#endif 

//clWSINT « "Pragma: no-cache\n"; 

clWSINT « "Content-type: text/html\n\n"; 

//Where to position the page, if all information is filed in, here. 

if (SnError) {clWSINT « "<A NAME=jump></A>";} 

//Output HTML 

ifstream ifpay, 

ifPay.open(clReg.m_szPayTemplate, ios::in | ios::nocreate); 

if (ifPay.failO) return (eRRCantOpenPayTemplate); //couldn't read pay template file 

//HTML Template 

while (ifPay) { 

ifPay.getline(szFileLine, BUFFER_SZ); 

if (!(pszTag = strstr(szFUeLine, DYNAMIC_TAG))) 

clWSINT « azFilcLinc « "\tT; 
else { 

nTagExist - TRUE; 

//Null the tag, Output the beginning of the line, 

//make the dynamic basket call, output the rest of the line 

if (stricn(szFileLinc) — strlen(DYNAMIC_TAG)) 

pszTag[0] = NULL; 
else { 

pszTag[0] = (char) NULL; 

pszTag += strlen(DYNAMIC_TAG) + 1; //was 9 

} 

clWSINT « szFUeLine; 
//Dynamic call 

pszRefererUrl « clWSINT.LookUp( 4< Refe^er ,, ); 
if (tpszRefererUrl) return (eRRNoRefererUrl); 
pszExePath - clWSINT.LookUp( w Executable Path"); 
if (! pszExePath) return (eRRNoExePath); 
pszServerNarne - clWSINT.LookUp^Servei Name"); 
if (! pszServerNarne) return (cRRNoServerName); 
clWSINT « "<FORM METHOD - POST ACTION = http"; 
if (clReg.m_nUseSSL) 
clWSINT « "s"; 
clWSINT « "jr « pszServerNarne « pszExePath « "#jump>"; 
rcIWSINT « "<FORM METHOD = POST ACTION « pszExePath « 

"#jump>";*/ 

//Setting Long Cookies 

clWSINT « "<CENTER>lf you wish to have billing and shipping defaults 
set in your browser, check this box 

« "clNPUT TYPE - CHECKBOX 
NAME«long_cookies> </CENTER>\n"; 
//Fill it in message 
if (nError) { 

clWSINT « "<A NAME-jump></A>"; 

clWSINT « * 4 <CENTER><H4>You must fill in <I>all</I> of the 
baling information except for <I>address line 2</I> and <I>email</l>.</H4></CENTER>"; 
} 

//GsoNum 

#ifdeL_SC 
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time(&tNow); //For multithreading, append instantiation number 
cIWSINT « "<TABLE ALIGN-RIGHTxTR>TH>Order 

Numbcr</IH><TD>" « tNow 

« "</TD></TR></TABLE><BR CLEAR=ALL>\n<INPUT 

TYPE=HIDDEN NAME=b_gso_num VALUE =" « tNow « ">\n"; 

#else 

//Pay page API: transaction type, GSO #, gso opaque 
pszGsoNum = c!WSINT.LootUp("b_gso_num"); 
if (pszGsoNum) 

clWSLNT « "<TABLE ALlGN=RIGHTxTRxTH>Order 
Number</THxTD>"« pszGsoNum 

« "<nt)></TR></TABLE><BR CLEAR-ALL>\n<INPUT 
TYPE-HIDDEN NAM E=b_gso_num VALUE =" « pszGsoNum « ">Vn"; 
else { 

timc(&tNow); //For multithreading, append instantiation number 
cIWSINT « "STABLE ALIGN=RIGHTxTRxTH>Order 

Number</THxTD>" « tNow 

« "</TD></TR></TABLE><BR C LEA R=ALL>\n< INPUT 

TYPE-HIDDEN NAME-b__gso_num VALUE - " « tNow « ">\n"; 

//Some pay page only specifics: transaction to execute, gso opaque 
pszTxn - clWSINT.LookUpCtransaction"); 
if (pszTxn) 

cIWSINT « "<INPUT TYPE-HIDDEN NAME-transaction VALUE - 

"« pszTxn << ">\n"; 

pszGsoOpaque = cIWSINT. Lookup ("gso_opaque"); 

if (pszGsoOpaque) 

cIWSINT « "< INPUT TYPE=HIDDEN NAME=gso_opaque VALUE = 
\""pszGsoOpaque « f V>\n"; 
tfendif 
#ifdef_SC 

//Bill to information & Payment Instrument 

eStat = AcquixeBUlHtmlfclWSINT, clBkGso.GetTbtO, -pProfUe, 

(EPCLCurrency) clReg.m_eDefaultCurrency); 

#clse 

//Pay Page alone requires a total 
pszTot - clWSINT.LookUp("totar); 
if (IpszTot) return (eRRNoPayTotal); 

eStat - AcquireBuIHtml(clWSINT, atoi(pszTot), *pProfile, (EPCLCurrency) 
clReg.m_eDcfaultCurrency); 

cIWSINT <c "<INPUT TYPE-HIDDEN NAME-total VALUE « pszTot < 

">\n"; 

#endif . , 

if (eStat !- eSuccess) return (eStat); //error from db? within 

Acquire Bill Html 

cIWSINT « "<P>\n"; 

//Output Buttons on Form 

pszShopUrl = cIWSINT. LookUp("shop_urr^); 

if (IpszShopUrl) 

PayButtonsHtmlfclWSINT, pszRefererUil, clReg); 

else 

PayButtonsHtml(clWSINT, pszShopUrl, clReg); 
//Registry Card Lookup 

cIWSINT « "<CENTERxTABLE CELLSPACING - 5><TR><TH>Cards 

Accepted :</TH>"; 

RegOpenKeyEx(clReg.m_hStoreKey J "APIWCDT", 0, KEY_READ, 

&hCardsKey); 

dwlen » sizeof(int); 

RegQueryValueEx(hCardsKey, "NoOfRows", 0, &dwtype, 
(LPBYTE)&nNoCards, &dwlen); 

for (int i = 0; i < nNoCajds; i++){ 

RegEnumKey(hCardsKey, i, szCardBuf, MAX_PATH + 1); 

RegOpenK£yEx(hCardsKcy, szCardBuf, 0, KEY_READ, 

&hCardKey); 

dwlen = MAX_PATH + 1; 

retcode = RegOuery\^lueEx(hCardKey 3 "Card Picture", 0, 
&dwtype, (LPBYTE)szCardPic, &dwlen); 

if (retCode != ERROR _SUCCESS) return eRRRegistry Failure; 
cIWSINT « **<TDx[MG SRC « szCardPic « ">-</TD>"; 
RegCloseKey(hCardKey); 

RegCloseKey(hcardsKey); 

cIWSINT « " <JTR > </TAB LEx/C ENTER > " ; 

cIWSINT « "</FORM>\n<HR>\n"; 

ffifdef _SC 

//Output static HTML Table 
clBkGso.ToHtml(cIWSINT, NOEDIT); 
//Output static Shipping information 
StaticShipHtmJ(clWSINT, 'pProfile); //Also NO_EDIT 
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tfclse 



#endif 



} 



cIWSDST « "<HR>\n*'; 

//Pay page alone takes and passes through a gso 
if (pszGsoOpaque) 

clWSINT « psiGsoOpaquc « \n"; 

//Rest of Line from template file 
if (pszTag) clWSINT « pszTag; 



} 

if (nTagExist !» TRUE) 

return (eRRNo DynamicTag); 

else 

return (eSuccess); 

} 

IIIIIlllHUIiltllllllllltftllU 
1} Receipt Page 

mimimmmuiimtmimmmunimmiumumiuimimm 

////////////////#idef_SC 

iummimiminimniMuuttmmiuimuummi 

fl StaticShipHtml 

// On Pay page, output Static table of shipping information 
// based on cookies set in prior page 

nimimmimmimMtmiiMitiimmnmniimi 

void StflticShipHiml(CWSINT& clWSINT, CProf clPrafile) 

clWSINT « " <CENTER> <TABLE CELLSPACING- lOxCAPTION ALIGN - TOPxB>Ship 
To<Bx/CAPTION>\n"; 

clWSINT « "<TRxTH ALIGN»LEFT>Namc<yTlI><TD>" « d Pro file. m_s„name « 

M </TD>" « 

"<TH ALI GN=LEFT> Address Line 1</TH><TD>" « clProfile.m_s_addrl « 
"VTDx/TRsAn"; 

clWSINT « "<TRxTH ALIGN=L£FT> Address Line 2</THxTD>" « cl Profile. m__s_addr2 

« "</TD>" « ™ ™ v 

"<TH ALIGN=LEFT>City</TH><TD>" « clProfile.m_j»_city « "</TDx/TR>\n ; 
clWSINT « "<TRxTH ALIGN-LEFT>State/P rovi nee </TH> <TD>" « clProfile. m_s_statc 
« "</TD>" « 

« "<TH ALIGN-LEFT>Zip/Postal Code</THxTD>" « d Pro file. m__s_zip « 
"</TD><yTR>Vn"; 

clWSINT « "<TR><TH ALIGN=LEFT>Counlry</THxTD>" « clProflle.m_s_country « 
"</TD>" « 

-<TH ALIGN-LEFT>Shipping Method </THxTD>" « cl Profile. m_s_sbip « 
"VTDx/TR>Vn"; 

clWSlNTT « " </TABLE> </CENTER > <P>' 

} 

#endif 

nimmmmiimmiminmiiimwummmm 

1} StaticBUlHtml 

// On Receipt page, output static table of billing information 

mMtimmtiiiiimiimmimmiiiuimiimmiMini 

void StaticBUlHtml(CWSINT& clWSINT, CProf clProfile) { 

/*<TH>Payment TVpeVTH>\n<TD>" « clProfile.m_b_instrument 
« "<JTD>'I 

clWSINT « " <CENTER> <TABLE CEIXSPACING-lOxCAPTlON ALIGN - TOPxB>BilI 
To<B></CAPnON>\n"; 

clWSINT « "<TR ALIGN- LEFTxTH> Account Numbcr</THxTD COLSPAN-3>" « 
clProfile.m_b_.card « "</TD><yTR>\n"; 

clWSINT « "<TR ALIGN=LEFTxTH>Name on Card</THxTD>" « dProfUe.m_b__name 

« 

u <AT>>«^^D><B>Expires:</B><I>Month</I> ,, « dProme.m_b_expire_month « 
"<I>Year</I>" « dProfile.m_b_expire_year « "</TD></TR>\n"; 

clWSINT « "<TR ALIGN-LEFT><TH> Address Line lcjTHxTD COLSPAN=3>" « 
clProfile.m_b_addrl « "</TD><fTR>W; 

clWSINT « "<TR ALIGN- LEFTxTH> Address Line 2</THxTD COLSPAN=3>" « 
dProfile,m_b_addr2 « "<vTDx/TR>\n"; 

clWSINT « "<TR ALIGN*-LEFTxTH>CLty</THxTD>" « clProfile. m_b_city « "</TD>" 

« "<TH>Statc/Province</THxTD>" « clProfile. m_b„slale « "<^TD></TR>\n M ; 
clWSINT « "<TR ALIGN=LEFTxTH>Country</THxTD>" « clProfiIe.m_.b_country « 
"</TDxTH> Zip/Postal Code<mi><TD>" « clProfile. m_b__zip « 
M </TDx/TR>\n"; 

clWSINT « "<TR ALlGN=LEF^^TH>Emaa</TH><TD>" « dProftle.m_b_email « 

« "<TH>Phone</THxTD>" « clProfile.m_b_phone « "</TDx/TR>\n"; 
clWSINT « M </TABLEx/CENTERxP>\n"; 
} 
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Default Gateway Configuration 

The VPOS is initially shipped enabled to connect to a 
default gateway with a single instance of a gateway defined 
that accesses a predefined site for testing of an installation 
before bringing it online in a production mode. The test 
installation contacts and converses with an actual gateway 
that simulates live transactions. After the installation checks 
out utilizing a set of test transactions, the test gateway 
downloads the pre -checked customizations to the installa- 
tion so that it can switch over to the production acquirer. 
This download processing is enabled in extensions to SET. 

Internet Transaction Gateway 



10 



which directs transactions to a particular host processor 
2250 for authorization processing in accordance with the 
present invention. 

Internet Payment Authorization 

The Gateway is a secure computer system that mediates 
transactions between the merchants' servers and a payment 
processor. The Gateway supports secure communications 
between merchants using the Internet on one side, and a 
processor using standard secure financial networks on the 
other side. Between the two interfaces, the Gateway main- 
tains a detailed log of all transactions, whether in-progress, 
completed, or failed. The Gateway accepts transactions from 



Payment methods that issue cards for conducting business merchants and converts them into legacy compatible formats 



utilize four major entities. These entities are the issuer, 
consumer, merchant and the acquirer. The issuing bank that 
provides the consumer with a credit card are usually not the 
same bank as the acquiring bank that serves the merchant. 
When the consumer utilizes a credit card to pay for a 
purchase, the merchant swipes the card through the POS 
terminal which makes a connection to the merchant's 
acquirer via the telephone network and transmits an autho- 
rization request with data read from the magnetic stripe. The 
acquirer's host processor, depending on the card number, 
will either perform local processing or switch the request to 
the correct issuing bank's host processor through the inter- 
change network. In a few seconds, the authorization 
response is returned to the originating POS indicating either 
an approval or a rejection. 

The Internet is a viable infrastructure for electronic com- 
merce. Ubiquitous browser software for the World Wide 
Web provides around-the-clock access to a large base of 
information content provided by Web servers. Utilizing a 
preferred embodiment, consumers using browsers can shop 35 
at virtual stores and malls presented as Web pages managed 
by the merchants'servers. Consumers can make purchases 
and pay for them using credit cards or other digital payment 
instruments in a secure manner. For such Internet-based 
payments to be authorized, a "gateway" is necessary at the 
back end to channel transactions to legacy processors and 
interchange networks. 

FIG. 21 is a detailed diagram of a multithreaded gateway 
engine in accordance with a preferred embodiment. Process- 



before forwarding them to the host processor. Responses 
from the host, after the reverse conversions, will be returned 
to the originating merchants. 
The Gateway performs many functions, including: 
Receives encrypted credit card transactions from the 

merchants via the Internet 
Unwraps and decrypts transactions 
Authenticates digital signatures of transactions based on 
certificates 

Supports all transaction types and card types 
Accepts concurrent transactions from each of the mer- 
chant servers 

Converts transaction data to legacy formats; forwards the 
mapped requests (in the clear) to a payment processor 
over existing communication links 
Converts transaction responses, correlates them with the 
original requests, and sends the mapped responses back 
to the merchants 
Provides logging, monitoring, reporting, and system 
administration 

FIG. 23 illustrates a Gateway's 2330 role in a network in 
accordance with a preferred embodiment. The Gateway 
2330 strictly conforms to all SET stipulations regarding 
40 certificate management, PKCS signed data encapsulation, 
PKCS encrypted data encapsulation, ASN.l representation, 
DER encoding, MIME encapsulation, and message sequenc- 
ing. A merchant server 2300 communicates via the Internet 
2310 using the SET protocol 2320 through a gateway server 



20 



25 



30 



ing commences when a TCP transaction 2100 is received by 45 2330 using a network interface processor 2340 to commu- 



a HTTPS Server 2102 and parsed to an appropriate Web 
Adaptor 2104 which posts an encrypted set transaction to the 
multithreaded gateway engine 2110. The encrypted SET 
request is received at a decryptor 2120, decrypted into a 
standard SET transaction and authenticated for converting 50 
by the forward converter 2124. Inside the forward converter 
2124, decides if the request is an original request, and honest 
retry attempt or a replay attack. The converted transaction is 
passed to the socket multiplexor 2130 to communicate via 
an existing communication link 2140 to a host computer. A 55 
security logger 2150 is also utilized for passing security 
records back via a database server 2160 to a database 
administration application 2190. A transaction logger 2155 
also utilizes the database server 2160 to capture transaction 



nicate to a legacy network 2360 in, for example the X.25 
protocol 2350. The legacy host 2370 ultimately receives and 
processes the transaction from the merchant server 2300 
without modification to its code. 

Internet Communication Protocols 

As discussed above, the TCP/IP protocol suite is utilized 
at the transport level. At the application level, in compliance 
with SET, all requests arrive at the Gateway in MIME 
encapsulated HTTP format. Similarly, all responses from the 
Gateway to the merchant servers will be transferred in 
HTTP. The HTTP protocol stipulates that a request-response 
pair will go through the same TCP connection and that the 



logs in a database 2180. Other system administration tasks 6 0 °ngm ator . in this case a merchant server will establish a 



2195 include a web server administration task 2190 which 
logs web hits in a log 2170. 

FIG. 22 is a flow diagram in accordance with a preferred 
embodiment. Processing flows from customers 2200 that are 
paying for products over the Internet or other communica- 65 
tion medium utilizing HTTPS or other protocols to one or 
more merchants 2210, 2220 or 2230 to a gateway 2240 



connection to send the request and will take down the 
connection when it has received the response. 

Host Payment Protocols 

Message colons performed by the Gateway will be sig- 
nificantly more than format transliterations: per-protocol 
differences in data elements and message semantics must be 
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considered carefully. Some of the transaction types that are ery from internal failures or external disasters that cause 
supported are listed below. physical damages to the system. Minimum-outage recovery 

is possible with redundant configurations of important com- 
ponents. 

■ s Site Redundancy 

Transaction Type The Gateway supports connections to a proprietary bank 

' — — network and supports mirrored disk arrays. 

Credit card sale with capture . _. , t 

Credit card sale without capture Location Redundancy 

Credit card sale with capture including avs (Master card and visa) The Gateway architecture supports location redundancy 

Credit card sale without capture including AVS (Mastercard and VISA) 1Q wnere a secondary remote System is Connected tO the 

Credit card return (Credit) nrimarv system via dedicated WAN links for software- 
Credit card post authorization (Force Post) r, * * 
Credit card post authorization (Force Post) with partial reversal support, driven database duplication, 
enhanced authorization data, and AVS result code (VISA) Scalability 

Credit card sale with capture - Void The Gateway software architecture, the choice of third- 
Credit card return (Credit) - vbid J5 software components, and the selection of hardware 

Totals request (for balancing) platforms enable the system to gracefully adapt and evolve 

to take on new demands in different dimensions. 

Tr „ t, * i The Gateway resides on an HP 9000 that is housed in a 

Host Communications Protocols ig „ ^ rack 

A virtual, private network between the Gateway and the 2 o 
host processor is established to expedite host communica- 
tion. In addition, two Network Interface Processors (NIP) ■ 

s— a "near end" NIP that interfaces to the Gateway and a Gateway Hardware Configuration 

"far end" NIP that interfaces to the host The MPs wiU ^ 

handle virtual connections between themselves. The lar-end 25 _ . 

NIP Will take care of Specific communication details. The K-Class SMP Server - Model K420 ■ Standard Configuration 

near-end NIP is an IP-addressable device that converts ^ ^ pA ^ ^ cpu 
between TCP messages and packets. It is installed on a ng ^ ECC 

public network 2330, which is a LAN OUtside the corporate Built-in I/O includes Fast/Wide/Differential SCSI-2, EtheiTVist 802.3 

firewall The Gateway, on the secure public network 2330, 30 LAN, A!;!, RS-232C Connectors, Centronics Parallel Port, and 

utilizes TCP/IP 2320 to communicate with the near-end NIP. w^Moto m Drive 

„ , ^ HP-UX 10.10 Operating System (with two-user License) 

Gateway Features 4 ^ pB s1oUj ^ 

Because the Gateway must sustain reliable operations and Additions 
enable graceful evolution, it is designed with some impor- 3 5 a SCSI _ 2 owe Controller 
tant attributes, including: Security, Availability, to support disk mirroring of dual SCSI-2 buses 

Performance, Scalability, and Manageability. 1 2 GB Internal SCSI-2 Disk Drive, 20MB/s transfer rate, not mirrored 
<J mritv ^ or 5 y stcm software and swap space 

Secuniy ^ 1 4 GB External High-Availability Disk Arrays 

Channel Security ^ for databases - total of 4 x 2 MB modules required 

At the application level, SET provides signed and 40 3 4 gb dat drive with data compression 
encrypted data encapsulations of payment information por- n hp-pb slot Expansion Option 

of the entire message packet is required for additional } for , icen3e for hp-ux 

security. The HTTPS protocol— i.e., HTTP over SSL3.0— is . 

utilized between the merchants and the Gateway. The virtual 45 . 

connections between the near-end NIP and the host are part Cryptographic Hardware 

of a private network. The termination will occur outside the The encryption and decryption algorithms used in pro- 
firewall. Data between the Gateway and the host is sent in ccssing SET/SSL messages require signuicant computa- 
the clear with no encryption. In this network configuration, riontl power. A "security ■processor' is deployed with the 
a transaction between a merchant's VPOS and the host will so Gateway to boost the performance of cryptographic algo- 
cross the firewall four times: SET request from VPOS to rithms. The processor is a networked peripheral device to the 
Gateway, legacy request from Gateway to NIP, LEGACY HP 9000 server. It provides cryptographic services suitable 
response* from NIPbl* to Gateway, and SET response from for SET/SSL processing, and its semens a« ac^ssible via 
Gateway back to VPOS. calls to software libraries running on HP-UX. FIG 24 is a 
Certificate Management 55 block diagram of the Gateway in accordance with a pre- 
payment Protocol Certificates fcrred embodiment. 

The Gateway uses certificates to authenticate the two Gateway Architecture 

parties involved in each MOSET transaction. Through a uonYu.^inin^r 

Certificate Authority, one certificate is issued for the Gate- .The Gateway runs under the HP-UX Vereion 10 . 10 oper- 

way and one certificate for each of the merchant servers. 60 «*? ^ •^SS^ZT^SS 

Secure Channel Certificates svs em reIeases - HP " UX 1010 conforms t0 maj0r standards ' 

SSL will require separate certificates for the Gateway and mc ' u * Dg, I IKTIV „, , , . ... ,. Q . , IINnv 

the merchants X/Open UNIX 95 (conformmg with the Single UNIX 

Specification, SPEC 1170) 

Availability 65 X/Open Portability Guide Issue 4 Base Profile (XPG4) 

Site redundancy and location redundancy allows the Gate- OSF AES 



way to sustain service through virtually instantaneous recov- IEEE POSIX 1003.1 and 1003.2 
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AT&T System V Interface Definition (SVID3 base and 

kernel extensions subset) Level 1 API support 
UC Berkeley Software Distribution 4.3 (BSD 4.3) includ- 
ing such features as job control, fast file system, 
symbolic links, long file names, and the C shell 
System V.4 File System Directory Layout 
This compliance with various software standards assures 
that while a preferred embodiment of the invention is 
disclosed in association with a best mode of practicing the 
invention other similar software and hardware environments 
can be readily substituted without undue experimentation. 
Relational Database Management System (RDBMS) Soft- 
ware 

The Gateway uses Oracle7 Server version 7.3 as the 
RDMBS and will be upgraded to use future significant 
system releases. The multi-threaded, multi-server architec- 
ture of Oracle7 provides applications with scalability to 
high-volume transaction workloads. When deployed with 
the HP 9000 K-Class platform, Oracle7 performs a sym- 
metrically parallel database operation across all available 
processors. In addition, Oracle7 includes options for creat- 
ing high-availability systems: 

The Oracle7 Parallel Server option extends the reliability 
of applications by transparently harnessing the power 
of clustered computers in a single logical processing 
complex that can tolerate individual machine failures. 
Oracle7 Symmetric Replication provides high data avail- 
ability. Data can be replicated from the primary system 
to one or more alternative sites. 

HTTP Server 

The Gateway utilizes Netscape's Enterprise Server 2.0 as 
the HTTP server. The server is designed for large-scale 
Internet commerce deployment, Enterprise Server 2.0 
achieves performance and reliability with such features as 
optimized caching, SMP support, enhanced memory 
management, andSNMP-bed performance monitoring. Effi- 
cient process management features minimize system load 
and increase server reliability. Security features are provided 
up the SSL 3.0 protocol. 

Protocol Stacks 

Internet and LAN— The TCP/IP protocol stack will be 
provided as part of the HP-UX operating system. 
Other Application-Level Protocols 

Application-level protocols enable client-server interop- 
erability. Each of the following protocols are transported 
using TCP or UDP 

HTML. HTML will be used to define screens for Gateway 

system administration. 
HTTP. The HTTP layer is part of Enterprise Server 2.0. 

The server is administered with a Web browser. 
SQL* Net. The Gateway's Oracle7 database can be 
accessed by administration clients using SQL* Net. 
Administration software can establish database connec- 
tivity to retrieve data for generating transaction reports. 
SNMP Enterprise Server 2.0 can be monitored using 
SNMP. The Gateway utilizes SNMP for remote system 
management. 

Transaction Performance Monitoring and Measurement 

The "hits" perform ance indicators are available from the 
Web server. Statistics can be generated at any time to 
high fight the load pattern or to pinpoint the time when the 
server was most active. 

Gateway statistics about transaction requests (by transac- 
tion type) and transaction results (e.g., success, failed due to 
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20 



host, failed due to authentication, etc.) can be determined at 
any time for a particular time interval by generating a report. 

The Gateway is upgradeable to inleroperate with a real- 
time event monitoring system such as OpenVision's Perfor- 
mance Manager. 
TokenOpaque Contents 

The Gateway requires information captured at the time of 
an AuthReq that must be repeated to the host at the time of 
the associated CapReq. The mechanism of choice (built into 
SET) for this is enabled utilizing this data in the TokenO- 
paque token of the CapToken which is sent in an AuthRes. 
This CspToken is stored at the Merchant system and repre- 
sented to the Gateway at the time of the CapReq. The format 
of an TokenOpaque is an OctetString. 

The following general format (not specific to LEGACY) 
is proposed for capturing this information: 



Field Name Field Data Type Explanation/Example 
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45 



VersionName 


char(8) 


e.g. "LEGACY" 


Version 


char(8) 


e.g "1.0" (generally <major, minor>) 


Revision 






PILenglh 


integer 


length of PI data 


PI 


unsigned char 


strongly encrypted 




(PILength) 




HostSpec 


integer 


length of host specific data 


DataLength 






HostSpecData 


unsigned 


host specific data 




char(HostSpec 






DataLength) 





Host Specific Data (LEGACY-only) 

For "LEGACY" version "1.0", it is proposed that newline 
separated "name[length]=value" pairs be used to store the 
host specific data. A null character will terminate the host 
specific data. The following host specific data (name value 
pairs) will need to be included: 

BrandID 

CPSACIFlag 

CPSTransactionld 

CPSValidationCode 

Visa Response Code 

MerchantCategoryCode 

EntryMode 
NOTE: PI contains PAN and ExpiryDate. 



Certificate Processing 

Merchants require a mechanism for verifying legitimate 

50 cardholders is of valid, branded bankcard account numbers. 
A preferred embodiment utilizes technology to link a card- 
holder to a specific bankcard account number and reduce the 
incidence of fraud and thereby the overall cost of payment 
processing. Processing includes a mechanism that allows 

55 cardholder confirmation that a merchant has a relationship 
with a financial institution allowing it to accept bankcard 
payments. Cardholders must also be provided with a way to 
identify merchants they can securely conduct electronic 
commerce. Merchant authentication is ensured by the use of 

60 digital signatures and merchant certificates. 

In a preferred embodiment, a holder of a payment instru- 
ment (cardholder) surfs the web (Internet) for required 
items. This is typically accomplished by using a browser to 
view on-line, catalog information on the merchant's World 

65 Wide Web page. However, order numbers can be selected 
from paper catalogs or a CD-ROM and entered manually 
into the system. This method allows a cardholder to select 
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the items to be purchased either automatically or manually. The Certificate Installation Helper Application 174 is 
Then, the cardholder is presented with an order form con- utilize to install a wallet that is issued by a bank. When the 
taining the list of items, their prices, and totals. The totals banks certificate issuance web system sends the MIME 
could include shipping, handling and taxes for example. The message containing the VeriFone wallet, the browser 
order form is delivered electronically from the merchant's s launches this application. This application queries a con- 
server or created on the cardholder's computer by electronic sumer to determine if the payment instrument contained in 
shopping software. An alternative embodiment supports a the wallet is to be copied to an existing wallet or to be kept 
negotiation for goods by presenting frequent shopper iden- in the new wallet. This application then installs ^ Payment 
tification and information about a competitor's prices. instrument and the certificate into the wallet database 158. 

Once the price of goods sold and the means of payment i« The Certificate Issuance CGI scripts 162 and the Single 

has been selected, tht merchant submits a completed order Account Wallet 160 at the Bank Web Site 182 is processed 

and Tc means for payment. The order and payment instruc- asdescribed in the aaUve system • ™« ^cate Installation 

lions are digitally signed by cardholders who possess cer- Applet of the Bank Web Site 182 isutilized by the Certificate 

tificates ^mercha^t then requests payment authorization Issuance CGI scripts 162 system to deliver a consumer s 

from the cardholders financial institution. Then, the mer- ™ certificate to the consumer s desktop, 

chant sends confirmation of the order, and eventually ships FIG. 26 is ao architecture block diagram in accordance 

the goods or performs the requested services from the order. with a preferred embodiment of the subject invention. Pro- 

The merchant also requests payment from the cardholder's cessing commences at function block 2600 where the 

financial institution. Graphical User Interface (GUI) part of the application is 

FIG. 1C is a block diagram of a payment processing 20 initialized. The GUI application 2600 provides the consumer 

system in accordance with a preferred embodiment. The wUb support for ordering and making W^»*™8g 

Certificate Issuance at the Bank Web Site 162 resides at the shopping process. There are also GUI component provided 

bank S s £ 182. It is utilized for issuing SET complain,/ for wallet creation; importing, ^"^J^ 

X 500 certificates to consumers. The implementation of this method creation and maintenance; and for transaction reg- 

system m y vary from one bank to another. However, the 25 ister review and reporting The screen designs an the r 

system gathers consumer's personal information, and after associated logic, for the helper ^cations and applets are 

processing the information, the system issues a certificate indrndually discussed in detail below, 

along with a payment instrument to the consumer. The Certificate Manager 2604 manages the automatic 

The Single Account Wallet 160 at the bank web site 182 30 downloading of a consumer's certificate from a bank vah- 

represen^the MIME message that is created by the Cer- elation of a consumer's and a m«M s certificates and 

tificate Issuance system. This MIME message contains a automatic requisite of certaficate renewal. 

VeriFone wallet. The VeriFone wallet contains a single The Payment Manager 2606 coordinates and completes 

payment instrument and the certificate associated with it. the payment request that is received from the merchant 

For security reasons, the private key is not included in the 3J system. The payment request is received via a MIME 

wallet The has to specify a private key before using the message in the native code implementation or via an applet 

instrument for payment. When the consumer is issued the in the Java implementation. The payment request received 

certificate, this MIME message is sent to the browser. The contains the final GSO, Ship-To name, merchant certificate, 

browser launches the Certificate Installation application 174, merchant URL, coupons and the payment amount The 

144 which is defined as a helper application in the browser. manager 2606 then communicates with the payment related 

The Certificate Installation application 174, 144 reads the GUI component to interact with the consumer to authorize 

MIME message and install the wallet into the wallet data- and complete the payment transaction. The manager is also 

base 158 responsible for determining the payment protocol based on 

Various helper applications 198, 172, 174, 176 are pro- consumers payment instrument and the merchant's pre- 

vided to make the consumer's shopping experience easy and 45 terred P a y mem P r0 '° ccu - ... AnnKnttinn 

efficient including the following helper applications. The Tne manager 2606 mcludes a ™U 

Paywindow helper application 188 is utilized by the con- Programming Interface (API) which enables OEMs to inter- 

suZ to authorize the payment to the merchant, to admin- face with the payment manager 2606 to make payments , to 

Ler their wallets, to review their previously completed specific HTTP sites. The detailed logic associated wuh the 

payment transactions and to perform housekeeping activities 50 payment manager 2606 is presented in HO. 27. 

on the wallets This application is defined as a 'helper' The payment manager 2606 enforces standard operations 

application on the consumer's desktop. The browser in the payment process. For example the receipt and the 

launches this application when the merchant system sends a transaction record can automatically be transferred to the 

MIME message requesting payment. Wallet file once the payment is completed. The payment 

The PayWindow Setup Helper application 172 is used by 55 manager architecture in accordance w,th a Purred 

the consumer to install helper applications and other mod- embodiment ,s presented m FIG. 27. A user mterface* w^ 

ules from the web site onto the consumer desktop. When a the payment manager 2730 via a user interface 27<K (that 

consumer attempts to install an application for a first time, responds to and sends a variety of transactions 2710, , 2708, 

the consumer d'oes no. have a helper application on the 2706, 2704 .and 2702 .Tne transactions mclude "b<*^« he 

desktop. Thus, the first time installation of an application 60 next record, payment record receipt ""P""* £ 

requires a consumer to perform two steps. Firs, the user must payment instrument and GSO component. In ^ turn the 
download .he system package to their desktop and then the payment manager 2730 sends transactions 2714 and receipt 

user must run Lup to decompress and install the system: 2720 to the waUet manager 2722 and receives paymen 
Thereafter, whenever the consumer gets a new release of instruments certificates and private keys from the wallet 
system software, the browser launches this helper applica- 65 manager 2722. 

lion which in turn installs the appropriate other system Tne payment manager 2730 also sends and receives 

modules transactions to the protocol manager 2770 including a mer- 
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chant's payment message 2760, a consumer certificate and 
PK handle 2750, a merchant URL 2742, a payment 2740, a 
signed receipt 2734 and a GSO, Selected Payment Protocol 
and Selected Payment Instrument 2732. The payment man- 
ager 2730 also accepts input from the payment applet or 
MIME message from the merchant as shown at function 
block 2780. One aspect of the payment processing is a 
Consumer Payments Class Library (CPCL) 2770 which 
encapsulates the payment protocols into a single API. By 
encapsulating the payment protocols, applications are insu- 
lated from protocol variations. A SET Protocol provides an 
implementation of the client-side component of the Secure 
Electronic Transaction (SEM) Protocol. A complete imple- 
mentation of the client-side component of the CyberCash 
micro-payment protocol is also provided. 

The Wallet Manager 2722 provides a standard interface to 
the wallet. It defines the wallet database structures and the 
payment instrument data structures, controls the access to 
the wallet and provides concurreny checking if more than 
one application attempts to open the same wallet The intern 
to the wallet manager 2722 is published to allow OEMs to 
interface with the wallet manager and access the wallet 
database. 

The wallet manager consists of the following sub- 
components: 

Wallet Access. This component provides an interface to 
read and write wallet information. 

Transaction Manager. This component provides an inter- 
face to read and write transaction corresponding to a 
wallet into the wallet database. 

Payment Instrument Manager. This component manager 
provides a common interface to the specific payment 
instrument access components. 

Credit Card Access, Debit Card Access, Check Access. 
These components deal with a specific payment instru- 
ment. 

A Data Manager provides storage and retrieval of generic 
data items and database records. It is assumed that data 
fields, index fields or entire data records can be marked as 
encrypted and the encryption process is largely automated. 
The data manager has no specific knowledge of database 
records appropriate to different payment methods. This layer 
is separated out so as to reduce changes required when new 
payment methods are introduced. However RSA key pairs 
and certificates might be considered as "simple" data types. 
This component also provides an abstraction which supports 
wallet files on computer disk or contained in smart cards. 

The Open Data Base Connectivity (ODBQ/Java Data 
Base Connectivity (JDBC) component provides Data Base 
Connectivity where formal database components are 
required. An embodiment of the Smart Card Wallet allows 
wallet data to be stored and/or secured by a cryptographic 
token. 

A preferred embodiment includes a single file or directory 
of files comprising a "wallet" which contains personal 
information and information about multiple payment meth- 
ods with the preferred implementation. These payment 
methods (Visa cards, debit cards, smart cards, micro- 
payments etc.) also contain information such as account 
numbers, certificates, key pairs, expiration dates etc. The 
wallet is envisaged to also contain all the receipts and 
transaction records pertaining to every payment made using 
the wallet. A Cryptographic API component provides a 
standard interface for RSA and related cryptographic soft- 
ware or hardware. This support includes encryption, 
signature, and key generation. Choice of key exchange 
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algorithm, symmetric encryption algorithm, and signature 
algorithm should all be configurable. A base class stipulates 
generic behavior, derived classes handle various semantic 
options (e.g. software based cryptography versus hardware 
5 based cryptography.) 

The Cryptographic Software portion provides RSA and 
DES support. This may be provided utilizing the SUN, RSA 
or Microsoft system components depending on the imple- 
mentation selected for a particular customer. Cryptographic 
Hardware creates a lower level API which can underpin the 
10 Cryptography API and be utilized to replace Cryptography 
Software with an off the shelf cryptography engine. The 
message sequence charts describe the flow of messages/data 
between the consumer, the browser and/or the various major 
components of the Semeru system. The major components 
15 of the system are the Merchant system which includes the 
VPOS, the PayWindow, and the Payment Gateway. The 
merchant system allows a consumer to shop, accept the 
payment transactions sent by the PayWindow application, 
and send payment transactions to the acquiring bank. The 
20 Consumer Payments Class Library (CPCL) module is a 
layer within the application which sends the payment 
transactions, securely, from the consumer to the merchant. 

FIG. 28 is a Consumer Payment Message Sequence 
Diagram in accordance with a preferred embodiment of the 
25 invention. The diagram presents the flow of messages 
between the consumer, the browser, the merchant system, 
the PayWindow application, and CPCL. This message flow 
describes the payment process from the time an order is 
completed and the consumer elects to pay, to the time the 
payment is approved and the receipt is returned to the 
30 consumer. The difference between the Native implementa- 
tion and Java implementation of the PayWindow application 
is in the delivery of the order information to the PayWindow. 
Once the order information is received by the PayWindow, 
the flow of messages/data is the same for both implemen- 
35 tations. In the case of the Native implementation, the order 
information is delivered via a MIME message. This MIME 
message is sent to the PayWindow by the browser via a 
document file. In the Java implementation, the order infor- 
mation is delivered to the PayWindow by an applet. The 
40 merchant system sends an applet with the order information 
to the browser which in turn delivers the order to the 
PayWindow. Once the order is received, the PayWindow 
interacts with the consumer and the Protocol modules for the 
completion of the payment process. 
45 Enters Order and Clicks Calculate Order 2820 

This message represent the consumer order entry and the 
clicking of the 'Calculate Order' button. The consumers 
shopping experience is all condensed into this one message 
flow for the purpose of highlighting the payment process. 
50 The actual implementation, of the shopping process varies, 
however, the purpose does not, which is the creation of the 
order. 

Order 2830 

This message represents the order information which is 
55 sent by the browser to the merchant via an HTML form. 
Payment Applet with GSO, PPPs, AIs, merchant certificate 
and URL 2840 

On receipt of the order, the merchant system calculates the 
payment amount. This message represents the HTML page 
60 which is sent by the merchant system detailing the payment 
amount along with the Java payment applet which contains 
the GSO, PPPs, AIs, merchant certificate and URL, 
Run Payment Applet 2845 
The Java enabled browser runs the Payment applet. The 
65 applet displays a button called "Pay" for the consumer to 
click. This is embedded in the HTML page delivered by the 
merchant. 
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Clicks Pay 2850 Payment instrument information is stored in the consum- 

This message represents the clicking of the Pay button on er*s wallet. The certificate which authorizes the payment 

the browser by the consumer after confirming the payment instrument will be stored along with that data in a secured 

amount database. The process of acquiring a certificate is described 

GSO PPPs AIs, merchant certificate and URL 2860 5 below. A certificate can be delivered to a consumer in a 

TWs message represents the GSO, PPPs, AIs, merchant preconfigured wallet. The consumer receives a wallet which 

certificate and the merchant URL carried by the Java applet contains the certificate together with the necessary details 

The Java applet now delivers these to the PayWindow associated with a payment instrument including a payment 

application instrument bitmap which is authorized by a certificate issu- 

Merchant certificate 2862 10 m authority or the agencies represented by the issuing 

This message represents the merchant's certificate which authority. 

is sent to the CPCL module for checking the validity of the t . ~ ^ , 

Obtaining a Certificate 

merchant. 

Merchant's validity 2864 A consumer will deliver or cause to be delivered infor- 

The CPCL modules mines the merchant's certificate and 15 ma tion to a certificate issuing authority. FIG. 29 in an 

send this message to the PayWindow indicating whether or illustration of a certificate issuance form in accordance with 

not the merchant is a valid merchant. a p re f erre d embodiment A use may fill out the form on-line, 

Wallet, Payment Instruments 2866 on paper m ^ ma il it in, or get his bank or credit card 

This message represents the wallets and payment instru- CO mpany to deliver it The consumer delivered data will 

ments that is displayed to the consumer. Not all payment 20 usua u y contain a public key belonging to a security key pair 

instruments from a wallet is shown to the consumer. Only generated by consumer software. This information will 

the ones accepted by the merchant is shown. normally be mailed to the consumer's address and actuated 

Payment Instrument 2868 b y a telephone call from the consumer. The certificate 

This message represents the payment instrument selected authority takes this information and uses it to validate that he 
by the consumer. This message is created in the current 25 ^ mdeec ] entitled to use the payment method. This process- 
design when the user double clicks on the payment image in ^ normally takes a few days to accomplish. Information 
the "Select Payment Method" Window. ^ normally be exchanged with the organization issuing 
GSO 2870 the payment method in the physical space if there is one, and 

This indicates that the GSO is displayed to the consumer Cfedit agenc j CS- The certificate information is loaded 

in the "Make Payment Authorization" screen. 30 ^ the consumer » s software to enable payment processing 

Authorization of Payment 2872 to pr0 ceed online. 

This message represents the authorization of the payment ^ {hc C0DSUmer ^ be able to se iect details 

by the consumer. The consumer authorizes the payment by ^ m instrument holder (wallet) he desires to 

clicking the "Accept" button on the "Payment Authonza- ^ ^ may ^ tfae icQn represeDting a holder , the access 

tion" screen. 35 passwor d or other information. After creating the certificate, 

Decide Payment Protocol 2874 me j^^g authority can use information received in the 

Once the consumer authorizes the payment, the payment certificale application to create a custom payment instrument 

protocol is decided by PayWindow based on the merchant s ^ {q ^ ^ payment instrument holder will 

Payment Protocol Preferences and the consumer selected ^ foUowing information. Payment instrument 

payment instrument. 40 m f ormat i orj including card number 2900 and expiration date 

Payment Authorization 2875 2W2. Personal information including name 2904, address 

These messages represent the merchant s URL, the Oi>u, 2m securit num ber 2908 and date of birth 2910. 

^^^^^^ m ji^^^ss^^ 

mis message repre&euifc ui P y . nt cvctpm ju, illustrates a certificate ssuance response in accordance with 

is sent by the protocol module to the Merchant system, ine ulusliaiL ^JL^a u;tm™ for a VISA 

GSO, P.! burner create and PK is package, use, on ^^^^Zf^ ££££ 

the payment protocol. and ^ paymcnt holtfcr nam6 m provided ^ lhe 

f^^SSSSr SSSy visfcle to him S,hL collection of payment 

**Zl^g^£^»~* is save, by the ss instrument Lder, HO. 31 

* / r , _fu,^^ ment instrument holders in accordance with a preferred 

PayWindow for tuture reference. embo diment. The predefined payment instrument holder 

Payment Successful 2882 JOHN'S WALLET that was predefined 

This indicates that the transaction receipt and the "pay- ^ AUU IS n k £ \ <?ZZ fnrm Flfi 52 

based on defaults bv the certificate issuance torm. riu. 3& 

ment successful" have been displayed to the consumer. uu u ^ idUI ^ u { u: tm .„ aoiwi a ™ 

ui^ui 60 illustrates the default payment instrument bitmap 321)0 asso- 

Certificate Processing ciated with the predefined payment instrument holder 3210 

A payment instrument must be certified by a "certificate resulting from the consumer filling in and obtaining 

issuing authority'' before it can be used on a computer approval for a VISA card. 

network. In the case of credit card payments, the issuer may FIG. 33 illustrates a selected payment instrument with a 
be one of tlie card issuing banks, but it might also be a 65 fill in the blanks for the cardholder m accordance with a 

merchant (eg SEARS), a transaction acquiring bank or an preferred embodiment. Next time the payment instrument 

association such as VISA or Mastercard. holder is opened in a payment context the certificate issuing 



06/10/2004, EAST Version: 1.4.1 



US 6,304, 

87 

authority's approved instrument bitmap can be used to select 
the payment instrument and utilize it to make purchases. 
FIG. 34 illustrates a coffee purchase utilizing the newly 
denned VISA card in accordance with a preferred embodi- 
ment of the invention. 5 

FIG. 35 is a flowchart of conditional authorization of 
payment in accordance with a preferred embodiment. Pro- 
cessing commences at 3500 where the program initializes 
the connection between the cardholder and the merchant for 
the purposes of shopping. After the cardholder completes io 
shopping, a new SSL connection is established which pro- 
vides authenticating information to the merchant. At this 
point the merchant is able to execute payment functionality 
(based on SSL or SET) conditionally, based upon the quality 
and character of the digital signature and the certificate used 15 
to validate said signature. Then, at function block 3510, the 
cardholder selects the payment instrument for the particular 
transaction. Payment instruments could include VISA, 
MASTERCARD, AMERICAN EXPRESS, CHECK, 
SMARTCARD or DEBIT CARDS. The payment method is 20 
then submitted to the merchant at function block 3520. The 
merchant then initializes the SET connection to the acquir- 
ing bank at function block 3530 if the connection is not 
already established. Then, at function block 3540, the cer- 
tificate is submitted to the merchant from the acquiring bank. 25 
The certificate includes a public key portion and a private 
key used as an irrebutable digital signature to authenticate 
the parties to the transaction. The certificate also includes 
information on the level of credit risk which allows a 
merchant to conditionally decide on the authorization or 30 
rejection of credit under a particular payment instrument 
based on their risk level and the merchant's personal com- 
fort level with the ability of the cardholder to pay. This 
processing has not previously been possible because the 
information returned from the authorizing bank did not 35 
include a level of credit risk a cardholder posed, it only 
contained credit rejected or approved. 

A detailed description of the gateway internals is pre- 
sented below in accordance with a preferred embodiment. 
Gw ClearSetRequestHandler 40 

FIG. 81 depict a flow diagram for the GatewayClearSe- 
tRequestHandler routine. Execution begins in Step 8108. In 
Step 8110 an SET analysis routine is called to analyz the 
SET request, as will be more fully disclosed below. Step 
5110 sets a status flag indicating the next stage to be 45 
performed by the Gateway. In Step 5120 the Gateway 
checks to see whether the status is set to indicate that a 
response should be provided to the user. If so, execution 
proceeds to Step 5190, which ends the request handling 
routine and returns control to a calling routine, which then 50 
provides a response to the user. Otherwise execution pro- 
ceeds to Step 5130. In Step 5130, the Gateway checks to see 
if the status is set to indicate that forward translation is 
required. Forward translation is necessary to translate an 
outgoing message into a format that can be understood by 55 
the host computer. If forward translation is indicated, execu- 
tion proceeds to Step 5135. In Step 5135, the outgoing 
message is forwarded translated, as more fully disclosed 
below with respect to FIG. 53. If no forward translation is 
indicated, for example, if an already-translated transaction is 60 
being retried, execution proceeds to Step 5140. In Step 5140, 
the Gateway checks to see if the next step is communication 
to the host. If so, the Gateway proceeds to Step 5145, and 
initiates host communication as will be more fully discussed 
below with respect to FIG. 54. If not, execution proceeds to 65 
Step 5150. In Step 5150, the Gateway checks to see whether 
reverse translation is indicated. Reverse translation trans- 
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lates a response from a host into a format useable by the 
calling routine. If reverse translation is indicated, execution 
proceeds to Step 5155, and the reverse translation is 
performed, as will be more fully discussed below with 
respect to FIG. 55. In any case, after either forward trans- 
lation in Step 5135, host communication in Step 5145, or 
reverse translation in Step 515, control returns to Step 5120 
for further processing. As will be more fully disclosed 
below, the forward translation, host communication, and 
reverse translation routines manipulate status indicators to 
prevent the occurrence of an infinite loop. 

The Gw_ClearSetRequestHandler routine as depicted in 
FIG. 31 may be implemented using the following C++ code: 
int Gw_ClearSetRequestHandler 
(CPCLRequest*pRequest) 



{ 

gwAction action; 
char fatalError; 

CPCLCCRequest *pVehicle = (CPCLCCRequest*) pRequest; 
CGW_Engine "setTrans - (CGW__EngLne ,[ ) pVehicle- 

>GetContext(); 

action - 6etTrans->AnalyzeSetRequest(p Vehicle &fatalError); 
whLlc ((action!=GW_PROCEED_TO_RESPOND)&& (! fatalError)) { 
switch (action) { 

case GW_P ROCEED_TO_FVVD_XL\T: 
action - setTrans->TianslateForward(p Vehicle); 
break; 

case GW JROCEED_WrTH_HOST_COMMS: 
action = setTrans->DoHostCommunication(p Vehicle); 
break; 

case GW_P ROCEED_TO_RE V_XLAP. 
action « setTrans->TranslateReveree(p Vehicle); 
break; 

case GW_PROCEED_TO_RESPOND: 
default: 
break; 

} 

// Response should be built, return up the protocol 
// stack so that it will encode and then crypt our response, 
if (fatalError) { 

// Set an error code for the protocol stack. 

pVehicle->SetError(eEInvalidRec|ucst); 

return (0); 

} 

else { 

return (1); 
} 

} 



AnalyzeSetRequest 

FIGS. 52A and 52B describe the AnalyzeSetRequest 
routine. This routine is by Step 5110 as illustrated in FIG. 51. 
Execution begins in Step 5200. In Step 5205 the various 
fields in the SET record are obtained, as will be more fully 
disclosed below with respect to FIGS. 56A and 56B. In Step 
5210 the Gateway checks the retry count. A retry count is 
zero indicates that the request being analyzed is a new 
request, and control proceeds to Step 5212, indicating a new 
request. If the retry account is non-zero, this means that the 
request is a retry of a prior request, and control proceeds to 
Step 5214 where a retry is indicated. 

Following either step 5212 or 5214, execution proceeds to 
Step 5215. In Step 5215 the Gateway checks to see whether 
the request represents a "stale request," as will be more fully 
described below with respect to FIG. 57, In Step 5220, the 
Gateway tests the result of the stale check from Step 5215. 
If the request is stale it is marked as stale in Step 5222. 
Otherwise the record is marked as not stale in Step 5224. 
Following either Step 5222 or Step 5224, control proceeds 
to Step 5230. In Step 5230 a message representing the SET 
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gwAction CGW_Engine ::Anal yzeSetRequest(CTCIXCRequest'p Vehicle, 

char 'fatal Error) 

{ 

gwAction action; 

gwDBRC dbrc; 

gwRC rc; 

int retryCount; 

char stale MsgFlag; 

*fatalError-_FALSE; // Default to "all is OK". 

// Extract the key SET fields that are required. The key 

//SET fields contain the primary key elements of the "setmsg" 

// table. 

if (Crc=GetSetKeyFields(p Vehicle))|- GW_SUCCESS) { 
switch(rc) { 
case GW_NOT_SUPPORTED: 

BuiidSetErrorResponse(pVehicle4SO_RESP_FUNC_ 
NOT_SUPP); 
break; 
default: 

BuildSetErrorRcsponse(pVehicle f ISO_RESP_SYS_ 

MALFUNC); 

break; 

* fatal Error-_TRUE; // Only place we return this! 

return (GW_PROCEED TO_RESPOND); 

} 

else { 

// Set this so that the front-end will be able to tell 

// whether enough information was derived from the request 



10 



request is inserted into the database for tracking purposes, 
and control proceeds to Step 5240. 

In Step 5240 the Gateway checks to we if the request had 
been marked stale in Step 5222. If so, it proceeds to Step 
5242, exiting with an error condition. In Step 5245, the 
Gateway attempts to retrieve from the database a message 
corresponding to the current SET request, as will be fully 
disclosed below with respect to FIG. 59. Step 5260 checks 
to see whether the message was successfully retrieved from 
the database. If the message was not found in the database, 
this indicates that the SET request represents a new message, 
and control proceeds to Step 5270. In Step 5270 a new 
message representing the SET request is added to the 
database, as is more fully disclosed below with respect to 
FIG. 60. Because this is a new request, it must be processed 15 
from the beginning, including forward translation. 
Therefore, after the new message is added in Step 5270, 
control proceeds to Step 5275. In step 5275, where a status 
flag is set indicating that the next step to be performed for 
this message is for translation. If the message was found in 20 
Step 5260, this indicates that the request represents a request 
that is already in progress. Therefore, control proceeds to 
Step 5280 to update the database with current information 
representing the request status. The update process is 
described in further detail with respect to FIG. 61, below. 25 
Following Step 5280, control proceeds to Step 5282. In Step 
5282 the Gateway checks to see the disposition in which the 
SET request was left as a result of partial processing. This 
is done, for example, by interrogating fields in the database 
record that indicate the steps that have already been per- 
formed for this request. In Step 5283, based upon this status 
information, the Gateway indicates the next stage of pro- 
cessing to be performed: either forward translation, reverse 
translation, or communication with the host. After this status 
has been set, whether for a new request in Step 5275, or for 35 
an already-existing request in Step 5283, control proceeds to 
Step 5290, which exits the AnalyzeSetRequest routine, 
returning control to Step 5110 in FIG. 51. The AnalyzeSe- 
tRequest routine as depicted in FIGS. 52A and 52B may be 
implemented using the following C++ code: 40 
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// in order to do update the "setmsg" log. 
m_haveKeyFields - 1; 



30 



// If the count of SET messages with current xid and rrpidbase is 
// non-zero then the message is an honest retry otherwise it 
// is a new request. 

if ((dbrc-Gwdb_GctSclMsgRetryCount(&retryCount>- - GWDB_ 
SUCCESS) { 

if (retryCount — 0) 

m_setRequcstClass= G W_S R EQC L_NEW_REQU EST; 

else 

m_setRequestClasB- GW_SREQCL_HONEST_RETRY; 

} 

else { 

BuildSetErrorResponse(pVchicIc > ISO_RESP_SYS_ 
MALFUNC); 

GW„LogError(LOG_ERR, "Gwdb_GetSetMsgRetryCount(): %S\ 
dbrc); 

return (GW_PROCEED__TO_RESPOND); 

// Check whether the message is stale. If it is, we still 
// insert it into the database shortly but we will not process 
//it. 

Gwdb_IsSetMsgStale(&staleMsgFlag); 
if (staleMsgFlag=_TRUE) 

m_selRequestDisposition« GW_SREQDI_STALE; 

else 

m_setRequestDisposition= GW_SREQDI_OK; // Not stale. 
// Log the "SET message" in the database. If the insert fails 
// then we must have a replay attack! 
dbrc - Gwdb_InsertSetMsgO; 
switch (dbrc) { 
case GWDB„SUCCESS: 
break; 

case GWDB_DUPLICATE_ON_INSERT: 

BiiUdSetErrorResponse(pVehicle4SO_RESP_SECURrrY_ 

VIOLATION); 

dbrc - Gwdb_InsertReplayAttackO; 
if (dbrc !- GWDB_SUCCESS) { 

GW_LogError(LOG_ERR, "Gwdb_InsertRcplayAttackO: 
%d", dbrc); 

return (GW_PROCEED_TO_RESPOND), 
break; 
default: 

BuiJdSetErrorREsponse(pVehicle,ISO_RESP_SYS_MALFUNC); 
GW_LogError(LOG_ERR, "Gwdb_InsertSctMsg(): dbrc); 
return (GW_FROCEED_TO_RESPOND>, 
break; 

} 

// If the message is stale do no more, 
if (m_setRequcstDisposition~ GW_SREQDI_STALE) { 

BuUdSetErrorResponse(pVehicle4SO_RESP_SECURITY_ 
VIOLATION); 

return (GW_PROCEED_TO_RESPOND>, 

// If we reach this far in this function then: 
// i) the request is new or an honest retry AND 

// ii) the request is not stale AND 

// Ui) a setmsg record has been added for this request. 

// If there is already a "host message" then update the key 
// with the new retry count. If there was not a "host message" 
// then insert one. 
dbrc - Gwdb_GetHostMsg(); 
55 switch(dbrc) { 

case GWDB_SUCCESS: 

dbrc «• Gwdb_UpdateHostMsgKeysO; 
break; 

case GWDB„ROW_NOT_FOUND: 
dbrc = Gwdb_InsertHostMsgO; 
if (dbrc 1= GWDB_SUCCESS) { 
60 BuildSetErrorRcsponsc(pVehicle ) ISO_RESP_SYS_ 
MALFUNC); 

Jeturn(GW_PROCEED_TO_FWD_XLAT); 
break; 
default: 

65 BuildSetErrorResponse(pVehicle 7 ISO_RESP_SYS_MALFUNC); 
GW _JjogError(LOG_ERR, "Gwdb_GetHostMsgO: %d", dbrc); 
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return (GW_PROCEED_TO_RESPOND); 
break; 

(dbrc t= GWDB_SUCCESS) { 

BuiIdSctErrorResponsc(pVchic]c,ISO_RESP_SYS_ 
MALFUNC); 

GW_LogError(LOG_ERR, "Gwdb_UpdateHostMsgKeysO, 
dbrc); 

return (GW_PROCEED_TO — RESPOND); 

[f this request is an honest retry then determine if we 
can "short circuit" a) the forward translation, b) the 
communications to the host or c) the reverse translation 
all of which will save time. 

(m_setRequcstClas5= GW_SREQCLc_HONEST_RETRY) { 
switch (m_hostResponseDisposition){ 
case GW _HRESDI_UNKNOWN: 

action = GW_P ROCEE D_TO_FW D_XLAT, 
break; 

case GW_HRESDI_RECEIVED_OK: 

action - GW_PROCEED_TO_REV_XLAT, 
break; 

case GW_HRESDI_i*EV_XLAT__FAILED: 
action - GW_PROCEED_TO_REV_XLAT, 
break; 

case GW_HRESDI_RECEIVE_FAIUED: 
case GW_HRESDI_TTMEOUT: 

action - GW_PROCEED_wrTH_HOST_COMMS; 

break; 
default: 

break; 

} 

return (action); 
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Translate Forward 

FIG. 53 depicts the execution of the TranslateForward 
routine, which is called by Step 5135 in FIG. 51. Execution 35 
begins at Step 5310. In Step 5320, the Gateway forward- 
translates the request to prepare it for transmission to the 
host. Forward translation consists of packaging the fields in 
the request into a format that is understandable by the legacy 
system at the financial institution. The exact format of the 
translated request will vary from institution to institution. 40 
However, in general, the format will consist of a fixed length 
record with predetermined fields, using a standard character 
set such as ASCII or EBCDIC. In Step 5330, the Gateway 
checks to see whether the translation was successfully 
performed. If not control proceeds to Step 5340, which 45 
returns an error condition. If the translation was successful, 
control proceeds to Step 5350. In Step 5350, the Gateway 
sets a status flag to indicate that the next stage to be 
performed for this SET request is to proceed to host com- 
munication. This, will be used in the next iteration of the 
Gw_ClearSetRequestHandler routine as depicted in FIG. 50 
51. After the status is set in Step 5380, the translate forward 
routine returns control in Step 5360. 

The TranslateForward routine as depicted in FIG. 51 may 
be implemented using the following C++ code: 

55 



gw Action CGW^ngme::TranslateForward(CPCLCCRequest*p Vehicle); 
{ 

gwRC rc; 

gwDBRC dbrc; 6Q 
rc - HM_TranslateForwaid(m_hostSpecificMessagep Vehicle); 
if ( rc == GW_SUCCESS) { 

return (GW_PROCEED_W|TH_HOST_COMMS); 

} 



DoHostCommunication 65 

FIG. 54 depicts the step of host communication, as shown 
in Step 5145 in FIG. 51. Execution begins in Step 5400. In 



Step 5406 the Gateway obtains from the request object the 
string representing the request text. In Step 5410 it obtains 
the sequence number for the request. In Step 5415 the 
Gateway determines the current time, in order to record the 
time at which the request is made. In Step 5420 the Gateway 
sends the request to the host and waits for a response from 
the host. When a response is received, execution continues 
in Step 5425. In Step 5425, the Gateway again checks the 
current time, thereby determining the time at which a 
response was received. In Step 5430, the Gateway checks to 
see whether the communication was successfully performed. 
If a communication was not successful, the Gateway records 
that an error occurred in Step 5432. If the communication 
was successful, the Gateway, in Step 5435, indicates that the 
request was successfully sent and responded to. In Step 
5437, the Gateway sets the response string based upon the 
response received in Step 5420. In Step 5439 the Gateway 
sets a status to indicate that reverse translation of the 
received response is required. Regardless of whether the 
communication was successful or unsuccessful, execution 
continues to Step 5450. In Step 5450, the database is updated 
with status information from the host communication. In 
Step 5490, control is returned to the calling routine. 

The DoHostCommunication routine as depicted in FIG. 
54 may be implemented using the following C++ code: 



gw Action CGW_Engine: iDoHostCommunication^PCLCCRequesfp 

Vehicle) 

{ 

gwHMRC hmrc; 
gwDBRC dbrc, 

gwAction action = GW_PROCEED_TO_RESPOND; 

unsigned char hostRequestMessage[HOSTREQ_SZ+ 1]; 

int hostRcqucstLcngth- 0; 

unsigned char hostResponseMessage[HOSTREQ_SZ+ 1]; 

int hostResponseLength- 0; 

long sequenceNo; 
HM_GetRequestString(m_hostSpecificMessage,&hoEt Request 
Message[0], 

fihostRequestLength); 
HM_GetSequencc No(m_hos tSpccifi cMessage, &sequcnceNo); 
time( &m_hostRequestTime); 
hmrc - SendTbHo8tAndWait( 

&hostRequestMessage[0].hostRequestLcngth f 
& hostResponseMessage[Ol & hostResponseLength); 
time( &m_hostRespon3cTime); 
switch(omrc) { 
case GWHM_SUCCESS; 

m_hostRequestDisposition= GW_HREQDI_ 
SENT__OK; 

m_hostRespoascDis position- GW_HRESDI_ 

RECElVED_OK; 
HM_SetResponseString(m__hos tSpecificMessage, & hos t 
RcsponseMessagefO ], 

hostResponseLength); 
action - GW_PROCEED_TO_REV_XLAT; 
break; 

case GWHM_SEND_FAELED: 

m_hostRcquest_Dispo5itioD- GW_HREQD1_ 
SEND__FAJ LED; 

m__ hostRcsponseDisposition- GW_ 

HRESDl_UNKNOWN; 

break; 

case GWHM_RCV_FAILED: 

m host Request Disposition- GW_HREQDI_ 

SENT_OK; 

m_host Response Disposition- GW_HRESDI_ 

RECEIVE_FAILED; 

break; 

case GWHM_RCV_TIMEOUT: 

m_host Request Dispos it ion= GW_HREQDI_ 

SEisrr_OK; 

m_Jiost Response Disposition- GW_ 
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HRESD I __TI M EO UT, 
break; 
default: 
break; 



} 



if (hmrc != GWHM_SUCCESS) { 

BuildSetErrorResponsc(pVehicle4SO„RESP_ 
lSSUER_INOP); 

dbrc « Gwdb_UpdatcHostMsgAlHnfo(scqucaceNo, 

&hostRequestMessage[0],hostRequestLeagai, 
&hostResponseMessage[OlhostResponseLength); 
if (dbrc != GWDB_SUCCESS) { 

BuildSetErrorRefiponsc03Vehicle4SO_RESF_ 
SYS_MALFUNC); 

GW„LogError(LOG_ERR, M Gwdb_UpdateHostMsg 
AlllnfoO: %d", dbrc); 

} 

return (action); 



setResponseCode); 

5 L{ 

m__bostResponseDisposition» GW_HRESDI_REV_ 
XLAT_FAILEI>, 

BuildSetEnorResponse(pVehicle,ISO_RESP_ 
INVALID_RESPONSE); 
dbrc = Gwdb„UpdateHostMsgResponseDispO; 
10 if (dbrc != GWDB_SUCCESS) { 

GW_LogError(LOG_ERR, "Gwdb_UpdateHost 
MsgResponseDisp 0 : 

%d", dbrc); 



TranslateReverse 

FIG. 55 depicts the operation of the TranslateReverse 
routine, as executed in Step 5155 in FIG. 51. Execution 
begins at Step 5500. In Step 5510 the Gateway reverse- 
translates the response received from the legacy system host. 
Reverse translation consists of extracting data from the data 
records received from the legacy system, and pacing them in 
objects so that they are useable by the Gateway. In Step 
5520, the Gateway checks to verify that translation was 
successful. If translation was successful control proceeds to 
Step 5530, where a status flag is set indicating a successful 
translation. If translation was not successful, control pro- 
ceeds to Step 5540, in which the Status Flag is set to indicate 
an unsuccessful translation. Regardless of whether transla- 
tion was successful or unsuccessful, execution proceeds to 
Step 5550. In Step 5550, a status flag is set to indicate that 
the next stage for the request is to provide a response from 
the Gateway. This step is always executed, because, regard- 
less of whether the translation or any other aspect of the 
transaction was successful, a response indicating either 
success or failure must be returned by the Gateway. Control 
then proceeds to Step 5590, in which the TranslateReverse 
routine returns control to the calling routine in FIG. 51. It 
will be seen that the Translate Forward routine in FIG. 53, the 
DoHostCommunication routine depicted in FIG. 54, and the 
TranslateReverse routine depicted in FIG. 55, each alter the 
status of the request. As a result as the loop depicted in FIG. 
51 executes a particular request will proceed through all 
three stages and finally to exit in Step 5190. 

The TranslateReverse routine as depicted in FIG. 55 may 
be implemented using the following C++ code: 



} 



15 



} 



// Whether there was a translation error or not we need to respond, 
return (GW_PROCEED_TO_RESPOND); 



GetSetKeyFields 

20 FIGS. 56A and 56B describe the GetSetKeyFields rou- 
tine. This routine is called by Step 5205 as illustrated in FIG. 
52A. Execution begins in Step 5600. In Step 5610, the 
Gateway interrogates the request object to determine the 
request type. In Step 5620, the Gateway determines whether 

25 the request type is for authorization only. If the request type 
is not for authorization only, execution proceeds to Step 
5625. In Step 5625, the Gateway checks to see whether the 
request type is for a sale. If the request type is neither for 
authorization only nor for a sale, execution proceeds to Step 

30 5630. In Step 5360, the Gateway indicates that the request 
type is not a supported request, and proceeds to Step 5635, 
where it returns to the caller. 

If the request type is either for authorization only or for a 
sale, execution proceeds with Step 5640. In step 5640, the 

35 Gateway initiate a container object to represent the request. 
In Step 5650, the Gateway extracts the [transaction 
identifier?] (XID) for the transaction. In Step 5652, the 
Gateway extracts the merchant identifier (MID) for the 
transaction. In Step 5654, the Gateway extracts the [what is 

40 the RRPID?] (RRPID) and the terminal identifier (TID) for 
the request. In Step 5656, the Gateway extracts the retry 
count associated with the current request. In Step 5660, a 
message data area is initialized with the extracted contents. 
The message area can then be used for further processing by 

45 the called routine. In Step 5690, the GetSetKeyFields rou- 
tine returns control to the caller. 

The GetSetKeyFields as depicted in FIGS. 56A and 56B 
may be implemented using the following C++ code: 
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gwRC CGW_Engine:<>etSetKeyFields(CPCLCCRequest" [ pVehicle) 



gwAction CGW_Engine::Traa5latcRcversc(CPCLCCRcquest ,t pVchicle) S5 
{ 

gwRC re; 
gwDBRC dbrc; 

rc - HM_TranslateReveree(m_hostSpecificMessagep Vehicle); 

if ( rc == GW_SUCCESS) { 

// Success; we have a normal PDU to send back to VPOS1 
// If there is any problem further to this (eg: PCL/ASN libs) 
// that the frond-end is responsible for calling the method 
// LogSetErrorResponseO on tllis engine instance. 
m_setResponseClas5* GW_SRESCL_APP_ 
NORMAL_PDU; 

m_setRcsponscDisposition= GW_SRESDI_ 
SENT_OK; 

!CM_G«tResponseCode(m_hostSpeciiicMessage,m_ 



^ gwRC transRc - GW_SUCCESS; 

unsigned int got; 

char s_Ripi<rndl2*XID_SZ]; 
unsigned long rrpid; 
unsigned long tidOffset; 

m_selKeyFields.reqType - pVehicle->GelRequestTypeO; 
switch(m_setKeyFields.reqType) { 
case CPCLRequest::CCAuthOnly: 
6Q case CPCLRequest::CCSale: 

// Initial cast to correct subclass. 
CASNAuthorizationRequestDatoContainer*s_req - 

((CPCLOCAuthOnlyRequest*)p\fchicle>>GetRequest 
ContaincrQ- 
>gct_data()- >gct_dataO; 
65 //xid 

s_rcq_>get_transactioii_idO->get_jc_id 0- > 
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get_value((unsigned char *) &m_seLKcy Fields jc id ,XID_ 

SZ> &got); 

//mid 

tfifdef JUNE_3RD 

strncpy(m_5ctKeyFiclds.mid,"42581", MID_SZ); 

#else 

// TODO: get code from Deepak for pulling MID out of s_ 
strncpy(m_setKcyFields.mid "42581", MID_SZ); 
//bahl 

#cndif 



req! 



//-■ 



NOTE: We have agreed with VPOS team that the RRPID field 
will contain the following: 

<rrpid> <spacc> <tid> <null> 

where <rrpid> is a string representing the rrpid value 
and <tid> is a string representing the tid value. 



mem&eu^RrpidTLdAO', sizeofi(s_RrpidTid)); 
s„req->get_AuthorizationRequestData_ extensionsQ-> 
get_auth_req_res_pair_id()- > 
get_value((unsigned char *) &s__RrpidTid f sizeof(s_ 
RrpidTid), &got); 
// get rrpid and offset to the tid. 
sscaaf(s_RrpidTid, "%d %n", &rrpid, AtidOffset); 
// rrpidBase and retryCount 
m_setKeyFields.retryCount- rrpid % 100; 
m_setKeyFields.rrpidBasc- rrpid - m_setKeyFiclds.retryCount; 
//tid 

strncpy(m_setKeyFields.tid,(s_Rrpidrid+tidOf&et),TID_SZ); 
// reqDate 

GW GetTuneFormASNTune(&(m 

5_req->get_authorization_requcst_date0; 

break; 



} 



// =« Void 



} 



case CPCLRequest::CCAuthReversal: 
case CPCLRequest::CCCreditRevereal: 
case CPCLRcquest::CCCapturc: 

case CPCLRequest::CCOedit: // ™ Refund | Return 

case CPCLRequest::CCOaptureReversal: // — \bid 

// case eBallnquiry: 

transRc - GW_NOT_SUPPORTED; 

bieak; 
default: 

transRc - GW_NOT_SUP PORTED; 
break; 

// Initialize the host message will with the key fields "in the clear"! 
if (m_hostSpecificMessage«= NULL) { 
transRc - GW__FAILED; 

} 

else { 

HM_Initialize(m_rKKtSpccificMessage,&in_setKeyRelds); 
return (transRc); 
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5725. In Step 5730, an indicator for this request is set to 
indicate that first time processing has already been per- 
formed for this request This flag in the same flag interro- 
gated in Step 5710, and is used to prevent successive 
reinitialization of the message life field. 

In Step 5740, the Gateway checks to see whether the 
merchant's time stamp, plus the value of the message life, is 
less than the time of the request. If so, then the request is 
considered stale, and is marked stale in Step 5750. If not, the 
request is not stale, and is marked not stale in Step 5755. 
Following either of Step 5750 or 5755, the Gwdb_ 
IsSetMsgStale exits in Step 5790. The Gwdb_ 
IsSetMsgStale routine as depicted in FIG. 57 may be imple- 
mented using the following C++ code: 



void CGW_Engine::Gwdb_IsSetMsgStale(char*staleFtag) 
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20 static char gotStaleDuration=0; 
static long setMsgLife; 

static char •funcName - "Gwdb_JsSetMsgStale"; 
// Only get this once per process lifetime, 
if (gotStaleDuration— 0) { 
FILE »fp; 

char duration(INI_MAXLNSZ+ 1]; 
if ((fp-OpenlniFileO) NULL) { 
setMsgLife - 0; 
(void) iniGetParameter(fp/GArEWAYADMIN", 

"SetMsgLife", duration); 

setMsgLife = atol (duration); // could return 0; handled later, 
(void) CloselniFile(fp); 

30 } 

if (setMsgLife «=0) { 

setMsgLife - 5 * 60; // Default to 5 minutes; 

} 

gotStaleDuration- 1; 

// If the message has expired its lifetime. 

if ((m_setKcyFields.merchantTline+setMsgUfe)<m_set 

RequestTime) 

*staleFlag-_TRUE; // request is stale. 

else . . , 

*staleFlag-_FALSE; // honour request, it is not stale. 

return; 

} 
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Gwdb_IsSetMsgStale 

FIG. 57 depicts the Gwdb__IsSetMsgStale routine. This 
routine is called by Step 5215 as illustrated in FIG. 52 
Execution begins in Step 5700. In Step 5710, the Gateway 
checks to see whether this is the fit time the Gwdb_ 
IsSetMsgStale has been called for this request. If this is the 
first time, Step 5715 through 5730 are performed; otherwise 
those steps are skipped. In Step 5715, a field representing the 
message life is initial to a predetermined duration. The 
message life is a field that will be used to determine how 60 
long the message representing the transaction will remain 
valid. The use of the message life field prevents a transaction 
that is effectively lost due to extensive processing delays 
from being processed. In Step 3720, the Gateway checks to 
see if the value of the message life is equal to zero. If the 65 
message life is equal to zero, a default value, i.e., 300 
seconds or 5 minutes, is assigned to the message life in Step 



Gwdb_InsertSetMsg 

FIG. 58 depicts the Gwdb__lnsertSetMsg routine. This 
routine is called from Step 5230 as illustrated in FIG. 52A. 
Execution begins in 5800. In Step 5810, the routine invokes 
a database insert function by, for example, executing an SQL 
INSERT command. In Step 5820, the database return code 
is obtained in order to be used as a return code from the 
Gwbd_InsertSetMsg routine. In Step 5830, a database com- 
mit function is performed, thereby instructing the database 
engine to commit the database changes to a permanent 
recording, i.e., by writing the information to the file, and/or 
by journalizing the change made by INSERT function. In 
Step 5890, the routine returns control to the calling program. 

The Gwdb_InsertSetMsg as depicted in FIG. 58 may be 
implemented using the following C++ code: 



gwDBRC CGW_Engme:<>wdb_InsertSelMsgO 

EXEC SQL BEGIN DECLARE SECTION; 
// Key. 

char *h_jrid - &(m_setKeyFiclds.xid[0l); 

long h_rrpidBase = m_setKeyFields. rrpidBase; 

wt h_rc try Count - m_setKeyFields.retry Count; 



06/10/2004, EAST Version: 1.4.1 



US 6,304,915 Bl 



97 



98 



-continued 



II Columns to insert into. 

char *h_mid - &(m_setKeyRclds.mid[0]); 

char *h__tid - &(m_sctKcyHclds.tid[Ol); 

char h_merchantTime[26]; 

int h„requcstTypc = (int) m_sctKcyFiclds.reqTypc; 

char h_requestTime[26]; 

int h„requestClass - (int) m_setRequestClass; 

int h__request - (int) m_setRequestDispcsition; 

Disposition 
char h_rc5ponscTimc(26]; 

int h_responseClass = (int) m_setRequestClass; 

int h_response - (int) m__setResponse Disposition; 

Disposition 

char *h_jesponseCode = m_setResponseCode; 
EXEC SQL END DECLARE SECTION; 
static char 'funcName = "Gwdb_InsertSetMsg"; 

gwDBRC dbrc; 
GW_MakeDat^tring(h_merchanlTime,&(m_setKeyFLclds. 

merchantlune)); 

GW^MakcDatcStringCh^rcqucstTunc^ir^setRcqucstTLmc); 
GW__MakeDateString(h_responseTime,&m„setRespon5eTLme); 

EXEC SQL INSERT INTO setmsg 



{ 



xid, rrpidbase, retrycount, mid, tid, 

merchanttime, 

requesttype, 

requesttime, 

requestclass, requestdisposition, 
responsetime, 

rcsponscclass, rcspoQ&cdisposition, rcsponsccodc 



VALUES 

{ 



:h_xid, :h_rrpidBase, :h_retryCount, 
:h_mid, :h tid, 

TO_DATE(:h_merchantTune,'DY MON 
DD HH24:MI:SS YYYY'), 
:h_requestType, 

TO_DATE(:h_requestTime,'DY MON 

DD HH24:MI:SS YYYY'), 

:h_requestClass, :h_requestDisposition, 

TO_DATE(:h_jcsponscTunc,'DY MON 

DD HH24:MI:SS YYYY*), 

:h__responseClass, :h_responseDiBposition, :h_ 

rcsponscCodc 



dbrc = Db_Error(funcName); 
(void) Db_Commit(funcName); 
return (dbrc); 
} 



gwDBRC CGW_Engine:<}wdb_GetHostMsgO 

5 struct tin requcstHmcTM; 

struct tm respoaseTimeTM; 
EXEC SQL BEGIN DECLARE SECTION; 
//Key. 

char *h_xid - &(m_6etKeyFields.XLd[0j); 

long h_jrpidBase - m_setKeyFields.rrpidBase 

10 // IndicatorV&riables. 

short h_requestStringInd; 
short h_responseStringInd; 
// Columns to rctrcive. 

long h_sequenceNo = 0; 
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Gwbd_GetHostMsg 

FIG. 59 depicts the Gwbd_GetHostMsg routine. This 
routine is called by Step 5245 as shown in FIG. 52B. 
Execution begins in Step 5900. In Step 5910, the routine 
invokes a database select function by, for example, execut- 
ing an SQL SELECT command. In Step 5920, the database 
return code is obtained in order to be used as a return code 
from the Gwbd_JnsertSetMsg routine. In Step 5930, the 
Gateway checks to see whether the database retrieve opera- 
tion was successfully performed. If so, execution proceeds 
to Step 5935. In Step 5935, the Gateway sets a number of 
status variables from the values retrieved from the database 
records. This includes the time the request was made, the 
time a response was received, the contents of the request 
string, the contents of the response string, and a sequence 
number for this request In Step 5940, a commit operation is 
performed. [What is the point of a commit operation fol- 
lowing a retrieval, as opposed to an insert or an update?] In 
Step 5900, control returns to the calling program. 

The Gwdb_GetHostMsg as depicted in FIG. 59 may be 
implemented using the following C++ code: 
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int 
int 
int 
int 
int 
int 
int 



int 
int 



int 

int 



*h_reqYear = &requestTimeTM.tm_year > 

*h rcqMonth = &rcqucstTimcTM.tm_mon; 

*h_reqDay » &requeslTimeTM.tm_mday; 
*h_reqHour - &requestTimeTM.tm_Jiour; 
*h__reqMinute - & requcstHmeTM . tm_min; 
*h_reqSecond - &requestTimeTM.tin_sec; 
*h_requestDisposition » (int *) &m__host Request 
Disposition; 
VARCHAR h_requeststring[128]; 

"■h_resYear = &responseTiineTM.lm_year; 
*h_resMonth - &responseTimeTM.tm„mon; 
*h__resDay - &rcsponscTimcTM.tm_mday; 
*h_resHour = & re sp o n seTim eTM . t m_hou r; 
*h_resMinute - &responseTLmeTM.tm_min; 
*h_resSecond = &responseTirneTM.tin_sec: 
int *h_responseDisposition - (int *) &m_host 

RcsponscDis position; 
VARCHAR h_responseString[128]; 
EXEC SQL END DECLARE SECTION; 

static char -funcName - "Gwdb_GetHostMsg"; 
gwDBRC dbrc; 

// Set the "tm" structures to null. Set tm_isdst to -1 so that the 

// mktimeO function will determine if whether Daylight Savings Tune 

// is active. 

memsetC&requeaTImcTK'NO*,, sizeof(tm)); 
requestTimeTM.tm_isdst—l ; 
memset(&resrxmscTimeTM,'\0', sizeof(tm)); 
responseTimeTM.tm_isdst=- 1 ; 
EXEC SQL SELECT 
sequenceno, 

TO_NUMBER(TO_CHAR(requesttime, ( YYYY*)) 

1900, // sec "man mktime" 

TO NUMBERCTO_CHAR(requesttime ) 'MM , ))-l, 

// see "man mktime" 

TO_NUMBER(TO_CHAR(requesttime/ DD*)), 
TO_NUMBER(TO_CHAR(requesttime/HH24')) ) 
TO_J^UMBER(TO_CHAR(rcquesttime,'MM')), 
TO_NUMBER(TO_CHAR(requesttime,' SS')); 
requestdisposition, requeststring, 

TO_NUMB ERCrO_CHAR(respanseLime/ YYYY ')> 1 900, 

// see "man mktime" 

TO_NUMBERCTO_CHAR(responsetime,' MM')>1 , 
// see "man mktime" 

TO__NUMBER(TO_CHAR(rcsponsctimc,' DD')), 

TD_NLrMDER(TO_CHAR(respQnseLime/HH24')), 

TO_NUM B ER(TO_CHAR(responsetime/ Mi ')), 

TO_NUMBER(TO_CHAR(rc5ponsetimc,'SS')), 
iesponsedisposition,responsestring 

INTO 
:h__sequenceNo, 

:h_reqYear, :h_reqMonth, :h_reqDay, :h_reqHour, :h_reqMinute, 
:h_reqSecoad, 

:h^requestDisposition, :h_requestStrmg:h_requestStringInd, 
:h_resYear, :h_resMonth, :h_resDay, :h_resHour, :h_resMinute, 
:h_resSecond, 

:h_responseDisposition, :h_responseString:h_responseStringlnd 
FROM 

hostmsg 
WHERE 

xid = :h_xid AND 

rrpidbase - :h_rrpidBase; 
dbrc = Db_Error(funcName); 
if (dbrc » GWDB_SUCCESS) { 

if (h_requestStringlnd== -1) h_rcquestString.len=0; 

if (h_responseStringInd= -1) h_jesponseString.len=0; 

m_hostRequestTime - mktime( ArequestTimeTM); 
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m_hostRespoiiseTime = mktime( &responseTimcTM); 
HM_Se tRequestS tring(m_hostSpecificMesage, 

h jcqucstString-arr, 

h_jequestString.len); 
HM_SctRcsponscString(m_hostSpccificMessagc, 

h responseString.arr, 

h_responseString. len); 
HM_SetSequcnceNoCin_JioslSpccificMessagc,h_scqucnceNo); 



} 



(void) Db_Commit(funcName); 
return (dbrc), 
} 



Gwdb_InsertHostMsg 

FIG. 60 depicts the Gwdb_InsertHostMsg routine. This 
routine is called by Step 5270 as illustrated in FIG. 52B. 
Execution begins in Step 6000. In Step 6010, the routine 
invokes a database insert function by, for example, execut- 
ing an SQL INSERT command. In Step 6020, the database 
return code is obtained in order to be used as a return code 
from the Gwbd__InsertSetMsg routine, in Step 6040, a 
commit operation is performed. In Step 6090, the routine 
returns control to the calling program. 

The Gwdb_InsertHostMsg as depicted in FIG. 60 may be 
implemented using the following C++ code: 



gwDBRC CGW„Engiiie::Gwdb_InsertHostM6gO 



= &(m_selKcyFields.xid[0]); 
- m_setKeyFields.rrpidBase; 
= m_sctKcy Fields. rctyrCount; 



EXEC SQL BEGIN DECLARE SECTION; 
// Key. 

char *h xid 

long h_rrpidBase 
in I h_rctryCount 
I) Columns to insert into 

long h scqucnccNo - 0; 

char h_requestTune[26]; 

int h_requestDisposiiion - (int) m_hostRequestDisposition; 

char h_rcspansc r nmc[2d}; 

int h_responseDisposition « (int) m_JiostResponse 

Disposition; 
EXEC SQL END DECLARE SECTION; 

static char *funcName - "Gwdb_InsertHostMsg"; 
gwDBRC dbrc; 

GW_Make DateString(h_requestTune, & m__hostRequestTime); 
GW_MakcDa teString (h_responseTimc,& m_bostResp onseTunc); 
EXEC SQL INSERT INTO hoslmsg 



{ 



xid, irpidbasc, retrycount, 

sequenceno, 

rcqucsttimc, 

requestdisposition, 

responsetime, 

respo nsedisposition 



VALUES 
{ 



}; 



:h_xid, :h_rrpidBase, :h_ 

rctryCount, 

:h_sequenceNo, 

TO_DATE(:h_rcqucsttimc,'DY MON 
DD HH24:MI:SS YYYY*), 
:h_requestDisposition, 
TO_DATE(:h_iesponseTimc/ DY MON 
DD HH24:MI:SS YYYY'), 
:h_rcsponse Disposition 



} 



dbrc - Db_Error(funcName); 
(void) Db_Commit(runcName); 
return (dbrc); 
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Step 6100. In Step 6110, the routine invokes a database 
update function by, for example, executing an SQL 
UPDATE command. In Step 6120, the database return code 
is obtained in order to be used as a return code from the 
Gwbd_UpdateSetMsgResponseInfo routine. In Step 6190, 
the routine returns control to the calling program. 

The Gwdb__UpdateSetMsgResponseInfo as depicted in 
FIG. 61 may be implemented using the following C++ code: 
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Gwdb_UpdateSetMsgResponseInfo 

FIG. 61 depicts a flow diagram for the Gwdb_ 
UpdateSetMsgResponselnfo routine. Execution begins at 
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gwDBRC CGW_Engine:<KwIb_UpdateSetMsgResponseInfoO 

EXEC SQL BEGIN DECLARE SECTION; 
// Key. 

char - h_jrid - &(m__setKeyFields.xid[0D; 

long h__rrpidBase = m_setKeyFields.rrpidBase; 

int h_retryCount - m_setKeyFields. retry Count; 

// Columns to update, 
char h_responseTime[26]; 

int h_responseClass - (int) m_actRcsponscClass; 

int h_response = (int) m_setResponse Disposition; 

Disposition 

char *h_rcsponsc Code - m_setRespoiiseCode; 
EXEC SQL END DECLARE SECTION; 

static char •funcNamc » "Gwdb_UpdateSetMsgResponseInfo"; 
gwDBRC dbrc; 

GW_MakeDaUString(h^esponseTmie ) &m_MtResrxinseTiine); 
EXEC SQL UPDATE setmsg SET 
responsetime - TO„DATE(:h_responseTime,'DY MON 
DD HH24:MI:SS YYYY'), 

responseclass = :h_responseClass, 

responsedisposition - :h_responseDisposition, 

responseoodc = :h_responseCode 
WHERE 

xid = :h_xid AND 

rrpidbase <= :h rrpidBase AND 

retrycount - :h_retryCount; 
dbrc - Db_Error(funcName); 
(void) Db_Commit(funcName); 
return (dbrc); 

}_ 

FIG. 62 is the main administration display for the Gate- 
way in accordance with a preferred embodiment. A set of 
menu selections are presented at 6200 which will be 
described in more detail for each display. FIG. 63 is a 
configuration panel in accordance with a preferred embodi- 
ment. The configuration panel provides access to manage- 
ment information for configuring a gateway management 
information database. The Merchant Identifier (Mid) 6310 is 
a thirty character, alphanumeric field that uniquely defines a 
merchant. The Merchant Name 6320 is a fifty character, 
alphanumeric field, the Edit 6330 and Delete field 6340 are 
hyperlinks to detailed panels for modifying information in 
the management information database. FIG. 64 is a host 
communication display for facilitating communication 
between the gateway and the acquirer payment host. The IP 
Address Field 6410 contains the Internet Protocol address 
for communicating via TCP/IP to the Internet. The TCP 
logical port field 6430 uniquely identifies the port for 
accessing the Internet, and the SAVE field 6430 invokes 
storing of the host communication information in the data- 
base. FIG. 65 is a Services display in accordance with a 
preferred embodiment. This display initiates portions of the 
Gateway such as the host multiplexer 2130 of FIG. 21. FIG. 
66 is a graphical representation of the gateway transaction 
database in accordance with a preferred embodiment. Each 
of the fields represents a portion of the internet database 
schema in accordance with a preferred embodiment. 

Gateway System Administration 
As described above, the gateway is a secure computer 
system that mediates Internet based payment transactions 
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between merchant servers and the acquiring bank's card host processor. The converter 6860 also converts messages 

processing host. The gateway supports secure communica- from the host processor to the format used by die SET library 

lions between merchants using the Internet and acquirers 6850. The multi-threaded gateway engine 6870 utilizes SET 

using private financial networks and maintains appropriate decryption and encryption and the host message converter 

loes of all transactions 5 <»860 to support simultaneous SET requests from multiple 

FIG 67 illustrates the gateway hardware architecture in VPOS terminals. The gateway also determines whether a 

accoriancV with a preferred embodiment. Internet 6730 plaintext SET request is an original request, an honest retty 

3f merchants communicate transaction information via attempt, or a replay attack. The possible results include fo 

m^chant servers 6700 running the VPOS software an honest retry, possibly because an earher response did not 

SlX o , gateway 6740. The gateway 6740 „ reach the VPOS, the gateway looks up the response firom the 

performs all conversion necessary to route transaction d atabase and returns ,t. K * * • »"«^«™» 

requests through the bank network 6750 to the host proces- logged If it is an onguul request, then tte WS en^ 

«^ R^ili* frnm the host leeacv svstem 6760 are proceeds to convert it to a host-specific request message. 

6740 which transfers the information through the Internet gateway host multiplexer 6890 and waits for a «SP°^™ 

6730 tottw merchant system 6700. 15 gateway also logs all intermediate P"^^« 

PIG. 68 is a block 'diagram setting forth the = y 

software architecture ^ ^.^^^J^^ Tnl ions'. THe gateway also converts host responses to 

embodiment. The gateway 6870 includes an SSL-comphant ju response objects, logs an error if the forward 

HTTP server 6800 that ^ensures t ^P°^l^y£ 20 £™ 

HTTP communication between ^v^M^te ™ * est , logs m err or if the gateway times 

acquirer's data operations center The VPOS transmits SET £ l 0 Js an error if the reverse conversion 

requests utilizing HTTP and public key certificates are used ol » mc r^puu^c <mu 

to facilitate authentication of merchant and gateway identity. tau ^ mmmiinicates with 

The HTTP server 6800 facilitates the communication The gateway host muluplexer 6890 co ^ mu " l ^ t ^ lt ^ 

bTtween the gateway 6870 and the VPOS terminals over the 25 the host tac d on the host's 10 adcjes, and port ^numberl 

Internet utilizing HTTP. The VPOS terminals are configured the host does not support TCP/IP, a link-level protocol 

to communicate 8 with the gateway utilizing the gateway IP converter must be installed. The gateway host multiple™ 

address and port number. The HTTP server 6800 also also sends multiple request messages to the host, serializes 

supports HTML pages for gateway system administration, them, and receives messages asynchronously irom the nost 

and utilizes Netscape's Enterprise Server 2.0 to support 30 and matches each of them with the corresponding request 

URL access to the port number. The administrative infor- message which allows a particular gateway process to stop 

mation contained on the gateway can be accessed by any waiting and proceed with the reverse conversion, 

commercial browser if the user has appropriate authority to The gateway 6870 stores all transaction information in a 

access the gateway. relational database 6845 controlled by a database server 

The gateway web adaptor 6820 is a Common Gateway 35 6840 and specifically designed for high transaction volume. 
Interface (CGI) program that is invoked by the HTTP Server The database also records the details and state of every 
6800 when a request arrives from a VPOS terminal. The web transactioo processed by the gateway and generates trans- 
adaptor 6820 extracts the contents of a posted transaction action reports utilizing the gateway administrative interface, 
and passes it to the SET library 6880 which decrypts the SET The sequence generator 6880 supplies the gateway with 
request into a plain text SET object utilizing the crypto- 40 unique sequence numbers utilized in host request messages 
graphic library 6810. The SET library 6850 then calls the for identification of each transaction. An optional host 
gateway engine 6870 to convert the plaintext SET object simulator resides on the gateway server and transparently 
into a host specific request message utilizing the host simulates a host for testing purposes. The gateway host 
message converter 6860. When a response is received, it is communication configuration screen can utilize the IP 
passed to the SET library 6850 for encryption utilizing the 45 address and port address of the host simulator to simulate a 
cryptographic library 6810. The encrypted SET response is host processor that receives host requests and supplies host 
sent back to the VPOS terminal. An error is logged if an responses for testing purposes, and returns an authorization 
invalid HTTP request is detected, if the library cannot approval response message appropriately formatted. During 
decrypt the SET response, or if the library cannot encrypt the normal transaction processing the host simulator is disabled 
SET response. Stale messages are rejected, 50 and the gateway communication configuration screen con- 

For credit card transactions, the gateway 6870 supports tains the IP address and port number of the host processor. 

Secure Electronic Transaction (SET) requests providing for The gateway includes a set of tools for administering 

message encryption, authentication and encapsulation. The gateway, database, operating system and Web server soft- 

SET library 6850, converts SET requests into messages that ware. Also, the database schemas and the gateway admin- 

are processed by the Host Message Converter. The SET 55 istrative interface allows system administrators to create 

Cryptographic library 6810 performs the following func- custom database reports to remotely monitor gateway per- 

tions. 1) Converts an encrypted byte stream from an HTTP formance. A gateway merchants display is provided to 

message sent by a POST method from a VPOS terminal to manage the merchant information on a gateway. Merchants 

a plaintext SET object representing the request; and 2) can be added, deleted or modified using a display. The 

converts a plaintext SET object representing the response 60 gateway also incorporates a system variable reflective of the 

into an encrypted byte stream which is transmitted back to maximum length of time to allow for a transaction request 

the originating VPOS terminal. The SET library 6850 uses to reach the gateway from the VPOS terminal. If the stale 

the cryptographic library for all standards based security message time limit is exceeded, then the transaction request 

operations. The cryptographic library also provides an inter- is rejected and the merchant must resend the transaction. AD 

face to the cryptographic hardware. 65 of the gateway tools are accessible from commercial brows- 

The host message converter 6860 converts messages to ers assuming the user requesting the access has appropriate 

bank-specific formats and routes messages to the appropriate authorization. 
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The gateway provides a secure server that mediates position to quickly develop and deploy our Internet payment 
transactions between merchants VPOS (Virtual Point-Of- solutions for the top Banks and acquirers. The Host Message 
Sale) servers and a financial institution's host processor. The interface (HM interface) will be used by the various soft- 
gateway supports secure communications between mer- ware development organizations of VeriFone to develop 
chants using the Internet on one side, and the host processor 5 software that will enable the gateway product to be deployed 
using legacy secure financial networks on the other side. with existing financial networks without changing the inter- 
Between the two interfaces, the gateway maintains a detailed face point to the financial network. Gateway, along with 
log of all transactions, whether completed or in-progress. VPOS allows the acquirers to offer Internet Payment solu- 
The gateway can handle multiple requests simultaneously Uons to their Merchant base without changing their current 
and is designed to be easily scaled to handle a high trans- to financial networks. 

action load. The VPOS software, although it too can be customized 

The gateway accepts transactions from merchants over and branded for a particular acquirer, is not as tightly 

the Internet and converts them to a host-specific format coupled with the financial network as is gateway. The 

before forwarding them to a host processor belonging to an protocol between the VPOS and gateway that is currently 

existing financial network. Responses from the host, after 15 use d is SET and this protocol, in principle, isolates the 

the reverse conversions, are returned to the originating VPOS software from the legacy network that it is ultimately 

merchants over the Internet. Transactions between VPOS connected to (via gateway), 
and the gateway are made secure by utilizing the SET 

protocol for all communication. Overview 

20 

. _ The host specific portion of gateway are accessed by the 

Gateway Core Engine Components gateway core engine by calling the functions contained in 

This document details a software interface between the the Host Message implementation. The software that imple- 

gateway core engine software component and the host ments the host message interface is linked to the gateway 

message specific software that implements the host specific , 5 core engine software either statically or dynamically (shared 

financfal message formatting and conversion functions. " object libraries in UNIX or DLLs on Windows NT). 11» 

The gateway performs the following functions: Host Message API is defined in this document. 

1. Receives encrypted payment requests from merchants, The softw«c that implements the host message interface 
as HTTP PO^messages via the Internet. must be re-entrant. Tne gateway engine wdl caU the host 
w B 30 message interface from either a process or a thread. Ine 

2. Unwraps and decrypts the requests. gateway engine is designed to be multi-threaded and will be 

3. Authenticates digital signatures of the requests based capable of handling multiple requests simultaneously. 

on certificates. ^ host message interface is a "C" based API. The 

4. Supports transaction types and card types as required implementation of the host specific library must be imple- 
by a financial institution. 35 me nted in "C++" as some of the data that is needed is 

5. Accepts concurrent VPOS transactions from each of the contained in "C++" objects and is only accessible using the 
merchant servers. methods for those objects. The host specific software need 

6 Converts transaction data to host-specific formats and only use very basic features of "C++" and need not be 
forward the mapped requests (in the clear) to the host completely designed and or programmed using object- 
processor using the existing financial network. *o oriented techniques. 

7. Receives transaction responses from the host. Transaction Types 

8. Converts the response from host-specific formats and 

correlate the mapped response with the original There are currently seven transaction types, or payment 

requests 45 request types, that can arrive at gateway from VPOS. Each 

9. Encrypts the responses, encapsulates them in HTTP of these request type has an associated request object and 
reply messages, and sends them back to the originating response object. There are methods that are made public for 
merchants over the Internet. each of these request objects that allow the host specific 

_ . . . t , ln , 0 module to "get" the data from the incoming request in order 

10. Provides transaction logging in a relational database, 8 ^ c ^ m ^ bUc 

symbolic transaction tracing, performance reporting, 50 ^ for ^ ^ aUowin tQe hosl 
and other systemaommistration rune ions * dala ^ wlU ^ 

communi- 

TT,e Host Message interface is the mterface between the * ^ back ^ 

gateway core engine and the host specific functions that WdWU u * & J * 
implement steps 6 through 8 in the above list. There may be VGATE API 

more than one Host Message implementation but only one 55 

vGATE core software implementation. FIG. 69 illustrates the gateway components and interfaces 

in accordance with a preferred embodiment. The gateway 
Host Message Interface API specifies the expected behaviors and information 

exchange for transaction processing functions, transaction 
Purpose 60 data structures, SET access functions, certificate manage- 

The Host Message interface grew from the desire to ment functions, string utility functions and system configu- 
separate the core functions of the gateway software from ration parameters. The architecture includes three distinct 
those functions that are host specific. There are a variety, sections to enhance distribution of the functions. The upper 
currently over 1,400 understood by VeriFone equipment and API 6910 consists of concise functions which are available 
software, of legacy financial networks and protocols that 65 via a call out interface to custom modules 6901-6903 
exist worldwide. We expect to have great demand for our provided by application developers. The lower API 6940 
VPOS and gateway payment solutions and must be in a allows the gateway 6930 and the custom modules 
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6901-6903 to call in to reusable helper functions 6950-6970 
which facilitate isolation from possible future fluctuations in 
structural definitions of SET data elements. The system 
configuration custom parameters 6920 include the more 
static information elements required for such things as the 
network address of the host or its proxy equipment, timeout 
values, expected length of certain messages and other sys- 
tem configuration information. These parameters are speci- 
fied as name-value pairs in the gateway system initialization 
file 
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The vGATE SET Access API shields application devel- 
opers from the structural complexities of the SET (Secure 
Electronic Transaction) protocol by providing high-level 
access functions to SET-defined data elements and allowing 
the use of such functions to be integrated seamlessly with the 15 
translations of a particular acquirer-specific message format. 
The need for the SET Access API is twofold: first, program 
abstraction and, second, separation of concerns. The forest 
of deeply nested data structures generated from compiling 
the textual SET ASN.l definitions is very tedious to traverse, 20 
and direct exposition to multiple levels of pointer manipu- 
lation is a major distraction in developing acquirer-driven 
custom applications for vGATE. Furthermore, the SET 
proposed standard, still in draft form, has been and is 
expected to be going through various revisions in which the 25 
ASN.l definitions are changed significantly. Any code that 
is involved in directly accessing the container structures will 
have to be rewritten. 

The above two software-engineering considerations are 
serious enough to warrant a solution using abstract repre- 
sentations and access methods. The vGATE SET Access API 
provides the application developers with a set of predefined 
classes for each of the SET messages with simple access 
methods to get data from, and set values to, the different 
elements of the SET protocol data units. The present content 
of the API is a current implementation of the PCL (Payment 
Class Library) 6950. In using the SET Access API, vGATE 
application developers will be able to insulate their code 
from all future fluctuations in SET structural definitions. For 
example, extensions to SET are segregated from the stan- 
dard SET functions utilizing an extend SET PCL 6960. 

The system is partitioned to separate design concerns at 
different levels and to allow for graceful adaptations by 
external modules. The language was selected for the API by 
recognizing, classifying, distilling and exposing the pro- 
grammatic activities that are typically required for translat- 
ing legacy payment protocols and in communicating with 
host processors. Within a generic framework of reusable, 
prefabricated components (the core gateway), points of 
access have been defined to allow customization activities to 
occur (gateway API). The resulting architecture allows a 
software developer to focus on custom applications by 
freeing them from the underlying operational details already 
handled by the gateway core engine. 55 

The gateway core handles basic transaction management 
(control flow, logging, error detection and recovery), inter- 
nal interprocess communication, relational database access, 
communication with vPOS terminals over the Internet, 
interfacing with a host processor via a legacy network, and 60 
overall system administration. Whereas the gateway con- 
trols the processing of payment messages, it has no embed- 
ded knowledge of any acquirer-specific payment protocols. 

The custom applications for a particular acquirer can be 
developed in C or C++ and linked to the gateway core 65 
software either statically or dynamically. If they are dynami- 
cally linked, then they are considered "shared objects" on 
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Unix or "dynamic link libraries'* on Windows NT. A gate- 
way installation consists of the core gateway engine and the 
custom modules designed for a particular acquirer 

While various embodiments have been described above, 
it should be understood that they have been presented by 
way of example only, and not limitation. Thus, the breadth 
and scope of a preferred embodiment should not be limited 
by any of the above described exemplary embodiments, but 
should be defined only in accordance with the following 
claims and their equivalents. 
What is claimed is: 

1. A method for processing information accumulated at a 
gateway between a network application and a host system 
utilizing a gateway administrative interface, comprising the 
steps of: 

(a) receiving information at the gateway from the net- 
work; 

(b) processing the information; 

(c) storing gateway transaction and administrative infor- 
mation at the gateway in a database; 

(d) receiving requests for gateway information from a 
network application at the gateway administrative 
interface and translating the requests into a query for 
the database; submitting the query to the database; 

(g) receiving gateway information from the database in 
response to the query; and 

(h) transmitting the gateway information to the network 
application. 

2. A method, as recited in claim 1, further comprising the 
step of processing requests for gateway from a browser 
utilizing the Internet. 

3. A method as recited in claim 1, wherein the gateway 
information includes dynamic tracing of transactions. 

4. A method as recited in claim 1, wherein the gateway 
information includes status information. 

5. A method as recited in claim 1, wherein the gateway 
information includes exception information associated with 
transactions. 

6. A method as recited in claim 1, wherein the network 
40 communication utilizes HTTP for information exchange. 

7. A method as recited in claim 1, wherein the gateway 
administrative interface provides system configuration 
parameters to the gateway. 

8. A method as recited in claim 1, wherein the gateway 
45 administrative interface activates gateway functions. 

9. A system for processing administrative information 
accumulated at a gateway between a network application 
and a host system utilizing a gateway administrative 
interface, comprising: 

(a) a network adaptor that receives encrypted information 
at the gateway from the network; 

(b) a software code segment that decrypts the information; 

(c) a first application program interface to access custom 
modules and process the information; 

(d) a database that stores gateway administrative infor- 
mation at the gateway; 

(e) a gateway administrative interface that receives 
requests for gateway information from a network appli- 
cation and translates the requests into a query for the 
database; 

(f) a software code segment that submits the query to the 
database; 

(g) a software code segment that receives gateway infor- 
mation from the database in response to the query; and 

(h) a software code segment that transmits the gateway 
information to the network application. 
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10. A system as recited in claim 9, further comprising the 
step of processing requests for gateway information from a 
browser utilizing the Internet. 

U. A system as recited in claim 9, wherein the gateway 
information includes dynamic tracing of transactions. 

12. A system as recited in claim 9, wherein the gateway 
information includes status information on transactions. 

13. A system as recited in claim 9, wherein the gateway 
information includes exception information associated with 
transactions. 

14. A method as recited in claim 9, wherein the network 
communication utilizes HTTP for information exchange. 

15. A computer program embodied on a computer- 
readable for processing administrative information accumu- 
lated at a gateway between a network application and a host 
system utilizing a gateway administrative interface, com- 
prising: 

(a) a code segment that receives encrypted information at 
the gateway from the network; 

(b) a code segment that decrypts the information; 

(c) a first application program interface to access custom 
modules and process the information; 

(d) a code segment that stores gateway administrative 
information at the gateway; 
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(e) a code segment that receives requests for gateway 
information from a network application and translates 
the requests into a query for the database; 

(f) a code segment that submits the query to the database; 
5 (g) a code segment that receives gateway information 

from the database in response to the query; and 
(h) a code segment that transmits the gateway information 
to the network application. 

16. A computer program as recited in claim 15, further 
io comprising a code segment that processes requests for 

gateway information from a browser utilizing the internet. 

17. A computer program as recited in claim 15, wherein 
the gateway information includes dynamic tracing of trans- 
actions. 

15 18. A computer program as recited in claim 15, wherein 
the gateway information includes status information on 
transactions. 

19. A computer program as recited in claim 15, wherein 
the gateway information includes exception information 

20 associated with transactions. 

20. A computer program as recited in claim 15, wherein 
the network communication utilizes HTTP for information 
exchange. 

***** 
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